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I.  INTRODUCTION 


A.  KEEPING  PACE  WITH  INFORMATION  TECHNOLOGY  WITHIN  THE 
DOD 

It  is  recognized  by  the  DoD,  the  Defense  Science  Board,  Congress,  the 
Government  Accounting  Office,  and,  most  importantly,  by  the  warfighters  themselves 
that  the  current  Integrated  Defense  Acquisition,  Technology,  and  Logistics  Life  Cycle 
Management  System  needs  overhauling,  specifically  for  acquiring  rapidly  evolving 
information  technology  systems  (Defense  Science  Board  [DSB],  2009;  Government 
Accountability  Office  [GAO],  2008,  2009a,  2009b,  2010).  Acquisition  in  the  DoD  spans 
a  wide  range  of  technologies  and  readiness  levels,  called  technology  readiness  levels 
(TRLs).  For  a  deeper  understanding  of  TRLs,  see  Appendix  A.  Among  the  highest 
readiness  levels  are  weapons  systems,  communications,  and  information  technology  (IT). 
Some  technologies  are  developed  specifically  for  military  use  and  others  are  commercial 
technologies  adapted  for  military  use.  Communications  and  IT  are  two  areas  that  borrow 
extensively  from  the  commercial  world.  With  private  funding  behind  them,  they  tend  to 
evolve  rapidly,  presenting  a  serious  challenge  to  DoD  acquisition.  While  adversaries  can 
adopt  these  technologies  quickly  through  online  resources  and  web  stores,  the  DoD  has  to 
follow  a  process  that,  in  many  ways,  is  the  same  process  used  for  acquiring  large-scale 
systems.  As  Deputy  Defense  Secretary  William  J.  Lynn  III  pointed  out,  the  process  has 
not  been  efficient: 

The  U.S.  military  is  the  most  capable  armed  force  in  the  world,  in  part, 
because  of  the  edge  given  by  the  reliance  on  information  technology,  but 
the  procurement  process  for  software  and  hardware  still  is  mired  in  the 
industrial  age,  tied  to  the  way  the  department  buys  tanks  or  ships  or 
aircraft.  In  this  very  ordered  process,  we  decide  what  the  mission  is, 
identify  the  requirements  that  are  needed  to  meet  that  mission  and  analyze 
alternatives  to  meet  those  requirements,  eight  or  nine  years  later,  we 
actually  have  something.  (Garamone,  2010) 


Currently,  the  DoD  acquires  technology  through  the  Integrated  Defense 
Acquisition,  Technology,  and  Logistics  Life  Cycle  Management  System.  This  system  is 
overwhelming  in  bureaucracy,  in  time,  and  in  complexity.  Appendix  B  contains  a  current 
pictorial  roadmap  of  the  entire  Integrated  Defense  Acquisition,  Technology,  and 
Logistics  Life  Cycle  Management  System.  Figure  1  shows  an  overview  of  this  process. 
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Figure  1.  Snapshot  of  Defense  Acquisitions  Life  Cycle  Management  System  (from 

Murphy,  2010) 

The  Integrated  Defense  Acquisition,  Technology,  and  Logistics  Life  Cycle 
Management  System  is  comprised  of  three  key  processes  that  must  work  together  to 
deliver  products  to  the  warfighter: 

•  The  requirements  process  (Joint  Capabilities  Integration  &  Development 
System,  JCIDS), 

•  The  acquisition  process  (Defense  Acquisition  System),  and 

•  The  program  and  budget  development  process  (Planning,  Programming, 
Budgeting,  and  Execution,  PPBE). 

Each  of  these  processes  is  governed  by  policies  from  multiple  DoD  documents. 
Furthermore,  under  DoD  Instruction  5000.02,  the  acquisition  process  is  broken  up  into 
phases  that  are  divided  by  major  decision  points  called  milestones.  In  Figure  1,  the 
milestones  are  represented  by  triangles  with  letters  inside.  Because  each  acquisition  is 
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unique,  the  acquisition  system  allows  DoD  acquisition  professionals  to  tailor  the  number 
of  phases  and  decision  points  inherent  in  each  program.  The  individual  tailoring 
available  is  graphically  shown  in  Appendix  B. 

To  further  complicate  IT  acquisition,  organizations  within  the  federal  government 
have  inserted  many  other  hurdles  into  the  process  through  either  policy  or  law.  One 
example  is  the  Department  of  Defense  Information  Assurance  Certification  and 
Accreditation  Process  (DIACAP),  a  required  process  for  all  IT  acquisitions.  The  process 
is  complex  and  time-consuming  in  order  to  achieve  and  maintain  the  required  authority  to 
operate  (ATO)  a  network.  The  DIACAP  process  requires  interaction  with  National 
Institute  of  Standards  and  Technology  (NIST)  guidelines.  The  NIST  is  an  agency 
responsible  for  developing  infonnation  security  guidelines  under  the  Federal  Information 
Security  Management  Act  (FISMA);  these  guidelines  can  be  accessed  on  the  NIST’s 
website  (http://csrc.nist.gov).  Two  NIST  special  publications  were  released  in  May  2010 
in  order  to  provide  more  clarity  and  to  streamline  the  Information  Assurance  Certification 
and  Accreditation  (IA  C&A)  process  by  including  the  following  documents:  (1) 
Recommended  Security  Controls  for  Federal  Information  Systems  and  Organizations , 
which  provides  a  common  risk  management  strategy  for  federal  security  (National 
Institute  of  Standards  and  Technology  [NIST],  2009);  and  (2)  Guide  for  Assessing  the 
Security  Controls  in  Federal  Information  Systems  and  Organizations ,  which  provides 
updated  assessment  techniques  and  procedures  (NIST,  2010).  These  documents  are 
considered  positive  steps  forward  because  they  are  current  and  reflect  known  issues  and 
time  concerns  faced  by  DoD  acquisition  professionals  during  the  IA  C&A  process.  The 
documents  also  provide  standards  on  which  the  industry  can  build  their  products  and  that 
will  then  speed  up  the  IA  C&A  process.  Despite  attempts  such  as  these  to  streamline  the 
DIACAP  process,  it  remains  woefully  cumbersome. 

The  National  Defense  Authorization  Act  (NDAA)  for  Fiscal  Year  2004  (2003)  is 
aimed  at  overcoming  these  burdens  when  the  need  is  life-threatening  and  urgent  (e.g., 
reinforcing  the  annor  on  all-terrain  vehicles).  IT  acquisition  normally  does  not  qualify 
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for  urgent  classification;  instead,  it  is  governed  by  the  rules  and  regulations  outlined  in 
the  Integrated  Defense  Acquisition,  Technology,  and  Logistics  Life  Cycle  Management 
System. 

For  commercial  information  technology  that  evolves  quickly,  a  more  nimble  and 
efficient  acquisition  process  is  needed.  This  technology  will  be  referred  to  in  this  thesis 
as  “Rapidly  Evolving  Information  Technology”  (REIT).  REIT  is  commercial  technology 
that  evolves  quickly  and  is  typically  information  technology  with  a  readiness  level  of  six 
or  greater.  It  demands  a  more  nimble  and  efficient  acquisition  process.  The  DoD  is  no 
longer  the  single  driving  force  behind  advanced  technology  acquisition  and  development. 
Consumer  demand  is  largely  driving  the  evolution  of  REIT.  The  DoD’s  acquisition 
strategy  for  such  technology  is  not  well  suited  for  this  shift  to  consumer  demand  driving 
acquisition  and  needs  to  evolve.  However,  the  process  needs  to  evolve  much  more 
rapidly  than  it  has  in  the  past. 

1.  A  Call  to  Arms 

IT  acquisition  reform  within  the  DoD  and  federal  government  is  an  ongoing 
effort.  For  decades,  laws  and  policies  have  been  changed  by  both  the  federal  government 
and  the  DoD.  The  DoD  has  attempted  to  improve  its  Integrated  Defense  Acquisition, 
Technology,  and  Logistics  Life  Cycle  Management  System.  The  Packard  Commission  of 
1986,  the  Clinger-Cohen  Act  of  1996,  the  National  Defense  Authorization  Acts,  and  the 
Defense  Science  Board  reports  are  just  a  few  examples  of  major  attempts  to  improve  the 
system  (Christensen,  Searle,  &  Vickery,  1999;  DSB,  2009;  NDAA  for  Fiscal  Year  1996, 
1996;  Ronald  W.  Reagan  NDAA  for  Fiscal  Year  2005,  2004).  Problems  with  cost, 
schedule,  and  perfonnance  recur  each  decade  as  the  DoD’s  needs  continue  to  exceed  its 
resources  and  abilities.  The  federal  government  continues  to  make  noble  efforts  to 
improve  the  process  of  the  overall  system,  but  improving  the  acquisition  of  REIT  needs 
additional  effort.  There  is  no  single,  efficient,  and  rapid  solution  for  acquiring  every 
software  application  or  new  piece  of  network  hardware.  In  many  cases,  REIT  advances 
faster  than  new  laws  and  policies  can  be  put  in  place  to  acquire  it.  In  addition  to  policy, 

people  and  technology  are  important  to  help  speed  up  the  Integrated  Defense  Acquisition, 
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Technology,  and  Logistics  Life  Cycle  Management  System.  Rarely  do  improvements  to 
just  one  process,  policy,  person,  or  technology  revise  the  overall  situation.  A  holistic 
approach  is  needed. 

On  October  28,  2009,  the  NDAA  for  Fiscal  Year  2010  directed  the  Secretary  of 
Defense  to  develop  and  implement  a  new  acquisition  process  for  IT  systems.  The  law 
also  directed  the  new  acquisition  process  to  include  the  findings  of  the  March  2009  report 
authored  by  the  Defense  Science  Board  Task  Force  and  titled  DoD  Policies  and 
Procedures  for  the  Acquisition  of  Information  Technology  (NDAA,  2009).  In  February 
2010,  the  Secretary  of  Defense  signed  the  DoD  Quadrennial  Defense  Review  (QDR), 
which  clearly  articulated  the  DoD  adherence  to  the  NDAA  for  Fiscal  Year  2010  under  the 
Reforming  How  We  Do  Business  section.  Specifically,  the  QDR  discusses  broad  topics, 
such  as  refonning  how  we  buy,  institutionalizing  the  rapid  acquisition  capability,  and 
strengthening  the  industrial  base.  In  addition  to  the  QDR,  the  NDAA  for  fiscal  year  2010 
established  Task  Force  804  to  provide  feedback  to  Congress  within  270  days  (Lenat  & 
Rode,  n.d.). 

2.  “Going  Embedded”  During  Research 

To  gain  a  new  perspective  on  the  problem,  I  embedded  inside  an  assortment  of 
system  commands  over  a  period  of  twelve  months.  Among  others,  these  commands 
included  MARCORSYSCOM.  Each  of  the  commands  provided  me  with  a  view  of  how 
information  technology  is  acquired  on  the  front  lines.  Each  command  had  improved  the 
acquisition  process  in  some  manner,  yet  those  improvements  were  not  normally  practiced 
by  the  other  commands.  Collectively,  their  processes  began  to  shape  a  new  process  that 
adapted  to  a  rapidly  changing  information  technology  landscape.  What  emerged  was  a 
process  that  has  been  dubbed  “Collective  Acquisition.”  This  Collective  Acquisition 
process  is  characterized  by  an  openness  of  the  commands  to  leverage  their  efforts  when  it 
comes  to  acquisition.  For  instance,  if  a  command  understands  where  the  potential 
cryptographic  weaknesses  are  in  getting  a  product  such  as  a  personal  digital  assistant 
from  one  vendor  certified  by  the  NSA  (National  Security  Agency)  for  classified  use,  then 
this  could  be  shared  with  another  command  and  perhaps  reduce  the  time  to  certify  a 
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different  product  from  the  same  vendor.  However,  there  are  many  obstacles  in  the  way 
of  making  Collective  Acquisition  a  reality.  Some  are  technical,  but  others  are  cultural. 
Each  of  these  obstacles  is  discussed  in  Chapter  IV. 

3.  Thesis  Outline 

The  remainder  of  this  thesis  outlines  a  framework  for  acquiring  rapidly  evolving 
technology,  or  for  Collective  Acquisition.  Chapter  II  contains  an  overview  of  the 
framework  for  Collective  Acquisition  and  provides  an  example  of  acquiring  information 
technology.  The  backbone  of  this  framework  is  a  new  type  of  information  exchange  that 
will  be  referred  to  as  the  Capabilities  and  Requirements  Clearinghouse  (CRC).  It  is 
much  more  than  a  data  repository  and  is  described  in  detail  in  Chapter  III.  Chapter  IV 
looks  at  barriers  to  adopting  the  new  framework.  Finally,  Chapter  V  addresses  its 
execution — steps  that  could  be  taken  to  put  the  framework  into  practice. 
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II.  COLLECTIVE  ACQUISITION 


A.  A  MOTIVATING  EXAMPLE 

The  term  Collective  Acquisition  was  chosen  to  highlight  its  collaborative  nature, 
which  is  key  to  providing  the  agility  necessary  to  acquire  technologies  that  evolve  very 
rapidly.  These  technologies  tend  to  be  information  technologies  and  fall  into  an 
acquisition  category  (ACAT)  three  classification.  No  longer  should  stakeholders  operate 
in  isolation.  Over  time,  their  work  should  be  leveraged  across  the  DoD  and  other 
agencies. 

An  example  will  help  to  illustrate  the  framework  for  acquiring  rapidly  evolving 
technology.  Suppose  two  vendors,  X  and  Y,  have  delivered  military  solutions,  perhaps  at 
different  times.  Each  has  delivered  a  system  comprised  of  vendor  components  under 
various  contracts  and  has  had  systems  certified  according  to  the  Joint  Interoperability 
Test  Command  (JITC)  standards.  These  contracts,  certifications,  costs,  etc.,  are  artifacts 
of  an  acquisition  that  can  be  reused.  Therefore,  Collective  Acquisition  comprises  an 
information  clearinghouse  called  Capabilities  and  Requirements  Clearinghouse  (CRC). 
The  CRC  is  populated  with  information  about  X’s  and  Y’s  previous  deliverables.  This  is 
the  capabilities  part  of  the  clearinghouse. 

Suppose  a  military  ground  unit  wants  to  deploy  a  new  technology  to  the  field  for 
biometrically  binding  users  to  cellular  phones  through  speaker  recognition,  making  it  so 
that  calls  placed  to  a  person  reach  that  person  no  matter  which  phone  they  are  using. 
After  all,  cell  phones  are  low-cost  alternatives  to  Joint  Tactical  Radio  Systems  (JTRS). 
Cell  phones  can  be  lost  or  stolen,  or  their  batteries  can  fail.  Tracking  phone  numbers  is 
not  feasible.  This  new  technology  will  be  referred  to  in  this  thesis  as  “SPKRCELL.” 

As  a  user  speaks,  SPKRCELL  recognizes  the  user’s  voice  and  then  associates  the 
user’s  identity  with  that  phone.  If  the  user  speaks  into  another  phone,  then  he  or  she  will 
become  identified  with  that  phone  instead.  To  call  a  person,  a  user  only  needs  to  refer  to 
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the  person  by  name  because  the  person’s  name  is  mapped  to  a  phone  number  by 
SPKRCELL  using  a  name  resolution  function  like  the  Domain  Name  System. 

Within  the  Collective  Acquisition  framework,  the  need  for  SPKRCELL  is 
communicated  initially  as  is  done  today  through  identifying  a  capability  gap,  such  as 
through  an  Operational  Deficiency  Report  (ODR).  The  ground  unit  would  complete  a 
standard,  one-page  ODR.  Appendix  A  contains  a  copy  of  the  ODR  used  today.  The 
following  is  an  overview  of  the  information  required  in  the  report: 

•  The  operational  requirement  (who,  what,  where,  when,  why,  how), 

•  The  capability  required, 

•  The  operational  deficiency,  and 

•  The  solution  to  be  employed. 

The  form  begins  and  is  maintained  as  a  digital  document,  which  is  submitted 
online  or  through  e-mail  to  the  requirements  branch  of  the  ground  unit’s  parent 
command.  These  reports,  though  governed  by  the  JCIDS  process  at  a  high  level,  may  be 
processed  or  handled  differently  at  lower  levels.  For  instance,  they  may  be  disseminated 
by  e-mail  in  some  cases  (pushed  to  users)  or  uploaded  to  a  website  in  others  (pulled  by 
users).  Collective  Acquisition  proposes  to  standardize  how  they  are  handled  by  storing 
them  in  the  CRC,  affording  uniform  access  to  them  across  the  DoD.  The  CRC  acts  as  a 
single  access  point  to  combine  infonnation,  people,  and  processes  from  the  entire 
command.  From  the  CRC,  all  future  stakeholders  in  the  process  have  the  ability  to  add 
and  edit  comments,  approve  content,  and  validate  the  report.  The  CRC  might  also  offer 
configurable  alerts  by  the  requirements  branch  so  that  stakeholders  can  be  notified  of  the 
need  for  SPKRCELL  technology  and  its  timeline  via  e-mail,  voice  mail,  text  messages, 
etc.  Within  minutes,  key  stakeholders  in  the  command  could  be  notified  of  the  new 
requirement  from  the  ground  unit,  leading  to  faster  validation  (invalidation)  of  the  report. 

Ultimately,  the  ODR  for  the  SPKRCELL  requirement  will  be  validated  or 
invalidated.  Either  way,  there  is  information  that  needs  to  be  cataloged.  For  instance,  it  is 
extremely  important  to  know  whether  the  SPKRCELL  ODR  was  not  validated  because  a 
stakeholder  like  the  NS  A  identified  a  security  vulnerability  or  whether  it  was  not 
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validated  by  default  because  the  deadline  for  comment  expired.  This  information  is 
stored  along  with  the  ODR  in  the  CRC.  If  a  similar  requirement  emerges  in  the  future, 
then  it  will  be  much  clearer  how  to  proceed  with  the  history  of  the  SPKRCELL  ODR 
available. 

Consider  a  scenario  in  which  the  SPKRCELL  ODR  is  validated  and  it  is  not 
urgent  (if  urgent,  a  different  path  needs  to  be  taken).  The  CRC  lifts  the  ODR’s  visibility 
to  an  approval  level.  Warfighters  and  personnel  at  the  requirements,  acquisition,  and 
budget  branches  all  have  access  to  the  SPKRCELL  ODR.  This  access  takes  place  at  a 
local  command  level  or  higher.  It  allows  enterprise-level  planners  to  see  if  the 
requirement  matches  other  requirements  at  higher  levels,  such  as  across  the  entire  DoD 
enterprise. 

The  CRC  has  a  powerful  search  feature  capable  of  matching  against  very 
unstructured  data — for  example,  images  and  audio  recordings.  The  CRC  searches  for 
artifacts  such  as  operational  deficiency  reports  and  documented  capabilities  related  to 
SPKRCELL  ODR.  The  search  may  even  occur  autonomously  after  the  CRC  is  updated 
with  the  SPKRCELL  ODR.  Suppose  the  search  reveals  that  vendor  X  once  delivered  a 
system  with  a  speaker  recognition  component,  and  vendor  Y  delivered  a  name  resolution 
system  for  personal  names.  At  this  stage,  an  acquisition  professional  might  wish  to 
pursue  integrating  these  components  to  meet  the  SPKRCELL  ODR.  This  person  would 
further  query  the  CRC  for  integrator  options.  Some  acquisition  professionals  do  not  have 
the  appropriate  expertise,  and  the  integrator  options  would  be  information  provided  by 
the  CRC.  For  the  sake  of  this  example,  suppose  integrator  Z  appears  to  be  a  good 
candidate.  The  CRC  provides  contact  information  for  all  the  parties  involved.  At  this 
point,  each  would  be  engaged  to  explore  the  feasibility  of  jointly  meeting  the  ODR  within 
suggested  budget  constraints. 

Suppose  X,  Y,  and  Z  have  come  up  with  a  cost  estimate  that  is  within  budget. 
The  Collective  Acquisition  framework  would  support  budget  management  through  a 
software  package  like  Quicken®  (http://www.quicken.com) — in  this  thesis  it  will  be 
referred  to  as  “QuickenGov.”  A  budget  expert  would  launch  QuickenGov  to  find  funding 
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for  X,  Y,  and  Z.  QuickenGov  would  replace  complex  Excel®  spreadsheets  and  provide  a 
better  user  interface,  like  those  sold  commercially  for  use  as  personal  finance  programs. 
It  would  also  provide  another  very  useful  feature:  QuickenGov  would  have  the  ability  to 
be  programmed  to  discover  opportunities  for  re-allocation  of  funding  based  on  success 
and  failure  criteria  and  on  the  overall  status  of  other  programs.  For  instance,  if  a  program 
failed  to  execute  to  a  specific  milestone  by  a  certain  time,  then  DoD  leadership  and 
acquisition  professionals  would  like  to  know  this  fact  because  it  presents  a  potential 
source  of  funds.  Suppose  SPKRCELL  hits  the  Program  Objective  Memorandum  (POM) 
process  in  an  off  year  and,  therefore,  does  not  have  funding.  In  this  case,  this  discovery 
feature  would  need  to  be  exploited  to  find  funding  from  another  program.  Further, 
suppose  we  discover  in  these  reports  three  programs  of  record  that  are  not  executing  their 
funding  in  the  current  quarter  and  are  identified  as  high  risk  for  failure  based  on  their 
status  reports.  In  order  to  provide  for  the  new  requirement  for  SPKRCELL  in  the  current 
quarter,  the  budget  expert  re-allocates  funding  from  the  failing  programs  into  a  new 
program  for  SPKRCELL  under  integrator  Z,  who  has  been  contracted  to  combine  vendor 
X’s  and  Y’s  components  into  a  system  that  meets  the  SPKRCELL  ODR.  The  Collective 
Acquisition  framework  provides  better  visibility  into  budget  and  suggests  ways  it  can  be 
re-allocated  if  necessary.  Of  course,  the  command  in  question  must  have  the  authority  to 
re-allocate  funding  within  the  current  fiscal  year. 

The  next  step  in  the  Collective  Acquisition  framework  would  be  to  develop  and 
execute  a  test  and  evaluation  plan.  The  contractual  plan  would  be  a  combination  of  input 
from  the  acquisition  professional  and  integrator  Z.  The  plan  would  include  milestones  as 
well  as  delivery  schedules  and  baseline  requirements  to  meet  at  each  milestone  (e.g.,  Beta 
version). 

The  acquisition  professional  would  use  his  or  her  experience  and  knowledge  as 
well  as  the  CRC  to  coordinate  what  he  or  she  expects  to  be  done  during  the  test  and 
evaluation  of  integrator  Z’s  implementation  of  SPKRCELL.  The  CRC  would  provide  a 
knowledge  base  for  lessons  learned  and  examples  of  acquisition  programs  that  have  been 
completed.  The  CRC  could  be  queried  to  discover  similar  infonnation  technology 
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systems  in  the  DoD,  which  could  then  be  leveraged  to  avoid  starting  acquisition  programs 
from  scratch.  Suppose  in  our  example  that  the  acquisition  professional  conducts  a  search 
for  programs  similar  to  SPKRCELL  based  on  the  ODR.  The  CRC  would  be  populated 
with  NIST  special  publications,  as  mentioned  in  Chapter  I.  As  such,  the  CRC  could 
detect  special  IA  C&A  testing  that  needs  to  be  done  that  perhaps  integrator  Z  did  not 
foresee.  The  acquisition  professional  would  be  aided  by  the  CRC  because  it  would  be 
working  in  the  background  to  notify  organizations  that  might  have  interest  in  a  new 
technology.  In  the  case  of  the  SPKRCELL  program,  the  CRC  would  alert  the  NSA  after 
SPKRCELL  was  approved  because  it  contained  references  to  speaker  recognition  and 
cellular  technology.  As  a  result,  the  NSA  would  have  been  given  the  opportunity  to  view 
information  about  the  vendors  chosen  to  implement  and  test  SPKRCELL.  Therefore,  the 
NSA  could  have  proactively  contacted  the  acquisition  professional  in  charge  of  the 
SPKRCELL  program  to  work  with  them  through  the  IA  C&A  process. 

As  part  of  the  Collective  Acquisition  framework  for  IA  C&A  and  for  test  and 
evaluation,  the  acquisition  professional  would  require  integrator  Z  to  use  a  testing  system 
available  today  called  the  IA  test  range.  The  IA  test  range  is  a  system  approved  by  the 
Designated  Approval  Authority  (DAA)  that  provides  a  risk-free  environment  for 
integrator  Z  to  quickly  assess  IA  compliance  and  meet  the  requirements  of  the  acquisition 
professional  (mandated  by  Chairman  of  the  Joint  Chiefs  of  Staff  Instruction  [CJCSI] 
3170.01  and  CJCSI  6212.01)  as  if  they  were  on  the  operational  network  (Chairman  of  the 
Joint  Chiefs  of  Staff  [CJCS],  2008,  2009).  The  concept  of  the  IA  test  range  replicates  an 
operational  physical  or  cellular  network  using  packet  generation,  virtual  machines,  and 
other  tools  to  mimic  bandwidth  constraints  and  software  programs.  An  important 
extension  of  the  test  range  is  its  ability  to  interface  with  the  CRC  in  two  directions.  Lirst, 
results  of  a  test  can  be  entered  into  the  CRC,  and,  second,  test  configurations  can  be 
loaded  from  the  CRC  into  the  IA  test  range. 

Lor  instance,  suppose  in  our  example  that  the  acquisition  professional  has 
discovered  that  the  NSA  is  concerned  about  speaker  recognition  being  vulnerable  to  man- 
in-the-middle  (MITM)  attacks.  The  professional  could  tailor  an  MITM  threat 
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configuration  for  the  IA  test  range  and  load  it  directly  from  the  CRC  into  the  test  range. 
The  CRC,  in  turn,  would  be  updated  directly  with  the  results  of  the  test  against  the  MITM 
threat. 

The  Collective  Acquisition  framework  comprises  powerful  search  techniques 
found  in  the  CRC.  But  the  framework  is  not  limited  to  just  the  CRC.  It  includes  new 
practices  such  as  key  interactions  between  stakeholders  at  various  stages.  These 
interactions  are  as  important  to  acquisition  as  the  CRC  itself. 
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III.  CAPABILITIES  AND  REQUIREMENTS  CLEARINGHOUSE 


The  CRC  is  new  technology — pieces  of  which  exist  in  various  fonns  today — and 
is  a  new  system  that  the  DoD  should  use  as  a  way  of  significantly  improving  the 
acquisition  of  REIT.  Some  commercial  software  programs  are  in  use  by  the  DoD  that 
help  the  matching  of  requirements  to  capabilities  during  the  acquisition  process.  IBM’s 
Rational  RequisitePro™  is  one  example  of  a  requirements  management  tool  with  the 
ability  to  trace  requirements  to  capabilities  (http://www- 
01.ibm.com/software/awdtools/reqpro/).  The  CRC  will  accomplish  more  than  the  IBM 
RequisitePro  because  the  CRC  will  be  done  through  logistics  life  cycle  management  and 
through  transparent  methods  of  sharing  and  analyzing  infonnation.  The  system  will 
streamline  the  market  research  and  analysis  of  alternatives  process  through  better  use  of 
information,  knowledge,  people,  processes,  and  technology.  The  goal  of  the  CRC  is  to 
accomplish  what  Bloomberg,  E-Trade,  and  other  companies  have  done  in  providing  in- 
depth  information  and  analysis  to  financial  companies,  bankers,  traders,  and  individual 
consumers.  The  CRC  will  provide  similar  information,  but  its  audience  will  be  the 
stakeholders  to  the  acquisition  process,  including  the  end  user. 

Initial  market  research  and  an  analysis  of  alternatives  are  important  steps  for 
cutting  down  the  time  it  takes  to  process  acquisitions  through  the  identification  of  proper 
material  solutions.  Products  with  a  TRL  of  six  or  greater  that  are  matched  to 
requirements  significantly  decrease  the  amount  of  time  the  acquisition  process  takes 
compared  to  low  TRLs.  The  current  practices  used  in  market  research  and  in  an  analysis 
of  alternatives  involve  studies  (independently  paid  for  through  contractors),  online  search 
engines,  other  online  resources  such  as  those  listed  in  Appendix  D,  and  individuals  who 
have  a  network  of  personnel  and  resources  to  lean  on  in  order  to  find  information.  All  of 
these  efforts  require  the  person  entering  the  requirement  to  make  an  extra  effort  to  find 
what  he  or  she  is  looking  for  or  to  make  the  determination  to  buy  the  technology  or  to 
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develop  it.  The  CRC  would  decrease  the  amount  of  time  required  for  market  research 
and  for  an  analysis  of  alternatives  as  well  as  provide  better  infonnation  than  what 
normally  would  be  found  scattered  between  a  multitude  of  resources. 

A.  HOW  DOES  IT  WORK? 

In  order  to  accomplish  these  goals,  the  CRC  would  need  to  be  a  central  repository 
or  gateway  to  information  used  for  the  collection,  dissemination,  and  transfer  of 
information  between  federal  systems  and  private  industry.  Interoperability  is  key  to  the 
success  of  the  CRC;  the  more  information  it  can  leverage  online — by  legacy  or  through 
private  industry — the  better  it  will  be.  The  power  of  the  CRC  will  be  in  bringing  together 
all  of  the  information  available  and  in  directing  the  right  information  to  the  acquisition 
professional  before  it  is  needed  or  in  demand. 

There  are  many  online  resources  providing  information  to  the  acquisition 
community,  but  many  of  these  resources  do  not  exchange  information  (see  Appendix  D). 
The  CRC  would  act  as  third-party  software  capable  of  pushing  and  pulling  information 
between  online  resources  (see  Figure  2)  while  maintaining  the  security  of  the  information 
and  protecting  that  information  in  accordance  with  laws  regarding  who  can  see  privileged 
information.  The  CRC  would  require  all  current  and  future  resources  to  be  interoperable 
(provide  hooks)  through  protocol  standards  that  would  encourage  the  sharing  of 
information.  The  information  accessible  through  the  online  sharing  of  resources  within 
the  CRC  would  make  up  the  backbone  of  dynamically  changing  information.  To  prevent 
duplication,  the  CRC  would  have  the  ability  to  search,  push,  and  pull  information  from 
these  online  resources,  but  not  necessarily  to  require  it  to  store  infonnation  on  its  own 
system  (which  would  duplicate  online  resources).  In  order  to  add  legitimacy  and  to 
ensure  the  use  of  the  CRC,  it  will  be  necessary  to  incorporate  into  the  system  all  of  the 
legacy  infonnation  that  the  DoD  has  until  everything  is  available  online.  Within  the 
DoD,  many  efforts  have  been  completed  to  digitize  the  large  number  of  documents 
necessary  to  complete  an  acquisition.  These  digitized  and  searchable  documents  would 
further  add  to  the  information  the  CRC  could  leverage. 
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The  federal  government  and  the  DoD  are  working  to  maximize  the  potential 
offered  by  software  and  the  Internet  in  order  to  improve  the  Integrated  Defense 
Acquisition,  Technology,  and  Logistics  Life  Cycle  Management  System.  Online 
initiatives  required  by  federal  law  and  DoD  policy  have  populated  the  Internet  with 
multiple  online  resources  related  to  acquisitions.  The  CRC  would  need  to  utilize  the 
existing  online  resources  in  order  to  be  a  truly  dynamic  and  useful  tool  in  the  acquisition 
system. 

Some  of  the  online  acquisition  initiatives  are  focused  on  specific  areas  of  interest, 
such  as  information  assurance.  Other  initiatives  are  focused  on  supplying  multiple 
features,  such  as  contractor  registration  and  performance  evaluations.  The  different 
online  resources  all  have  one  goal  in  common:  to  provide  better  services  to  the  user  in 
order  to  help  streamline  the  acquisition  process.  However,  the  online  resources  overlap 
in  some  cases  and  most  of  the  time  do  not  dynamically  share  their  information  with  each 
other.  Furthermore,  since  there  are  so  many  websites,  it  is  difficult  for  users  to  remember 
all  of  the  information  available  and  to  search  each  one,  creating  inefficiency  in  the 
acquisition  process. 

A  serious  effort  should  be  made  to  dynamically  share  the  information  between  the 
online  resources  and  to  standardize  protocols  in  order  to  make  the  transfer  of  data 
between  them  seamless.  A  consolidation  effort  should  also  take  place  to  decrease  the 
number  of  individual  online  resources;  there  should  be  fewer  interconnected  resources, 
and  there  should  be  a  third-party  system  that  relates  the  sites,  such  as  the  CRC.  The 
dynamic  sharing  of  infonnation  across  the  online  resources  could  be  accomplished  with 
the  CRC  acting  as  a  third-party  application. 

One  approach  to  consolidating  the  online  resources  available  is  by  accessing  them 
through  a  single  website.  The  Integrated  Acquisition  Environment  (IAE)  website, 
sponsored  by  the  E-Gov  Initiative,  states  that  it  “provides  one  Web  site  for  all  things 
acquisition”  (https://www.acquisition.gov/index.asp).  This  website  does  not  include 
everything  related  to  acquisition,  but  it  makes  a  great  effort  to  advertise  online  resources 
and  tools  available  to  the  government  and  industry.  The  goal  of  the  website  is  to  simplify 
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and  streamline  the  federal  acquisition  process  for  government  and  industry  by  providing 
more  efficient  and  transparent  practices  through  links  to  online  resources.  It  is  refreshing 
to  see  that  there  is  an  organization  dedicated  to  improving  the  online  efforts  of  the 
acquisition  community,  but  more  can  be  done  to  open  up  the  online  resources  to  each 
other  and  to  leverage  collective  power.  The  CRC  could  act  as  this  force  multiplier  by 
utilizing  these  resources  collectively  (see  Figure  2).  The  IAE  is  a  noble  effort  to  bring 
online  links  to  one  website,  but  it  does  not  provide  the  relationships  between  the 
resources  that  need  to  exist  in  order  to  leverage  the  resources  of  the  federal  government 
and  to  streamline  the  acquisition  system. 


Figure  2.  Sample  online  resource  relational  model 

1.  Stakeholders 

In  order  to  make  the  CRC  relevant  and  useful  for  REIT,  it  should  involve 
important  stakeholders  within  the  Integrated  Defense  Acquisition,  Technology,  and 


16 


Logistics  Life  Cycle  Management  System.  The  following  is  a  list  of  the  initial 
stakeholders: 

•  Requirements  generators  (operators); 

•  Private  industry  (Google,  Cisco,  BAE,  small-business  owners,  etc.); 

•  Government  research  labs  and  institutions  (Federal  Laboratory 
Consortium); 

•  Acquisition  professionals; 

•  Budget  professionals; 

•  IA  organizations  and  policy-makers  (NSA,  NIST);  and 

•  Interoperability  organizations  (Defense  Technical  Infonnation  Center, 

DTIC). 

The  stakeholders  listed  are  the  most  important  decision-makers,  individuals,  and 
organizations  that  would  benefit  the  most  from  the  CRC.  Furthermore,  they  would 
provide  the  most  information  and  feedback  for  CRC  adaptive  learning.  This  is  not  an  all- 
inclusive  list;  more  should  be  added  by  DoD  acquisition  professionals  as  needed  for  CRC 
efficiency. 

2.  Incentivize  Stakeholders 

The  CRC  will  only  be  a  requirements  and  information  depository,  similar  to  DoD 
Techipedia  and  the  Joint  Requirements  Oversight  Council  (JROC)  online,  unless  the  DoD 
can  incentivize  the  stakeholders  to  enter  past,  present,  and  future  capabilities  into  the 
CRC.  In  a  memorandum  from  the  Under  Secretary  of  Defense  for  Acquisition, 
Technology,  and  Logistics  (USD[AT&L])  issued  in  2001,  the  DoD  attacked  the  incentive 
problem  facing  the  acquisition  industry.  The  usefulness  of  the  CRC  is  defined  by  its 
ability  to  access  other  resources  and  legacy  systems  and,  in  general,  to  crawl  through 
information.  The  CRC  requires  a  well-defined  incentive  proposition  for  all  of  the 
stakeholders.  Entering  information  could  be  accomplished  in  a  similar  fashion  to  the  way 
information  is  entered  into  the  classification  system  used  for  the  capabilities  documents 
of  the  DoD.  For  instance,  most  capabilities  are  associated  with  products  that  have 
brochures  or  product  summaries.  Using  the  intelligent  system  to  classify  these 

documents  would  help  expedite  the  input  of  information  into  the  CRC  system. 
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Requirements  generators  would  be  the  easiest  group  to  incentivize  because  they 
would  see  returns  on  their  input  investment  faster  than  before  they  used  the  CRC.  It 
would  be  important  to  initially  track  and  advertise  the  time  spent  from  requirement  input 
to  product-in-hand  and  to  report  this  information  back  to  requirements  generators  and  the 
chain  of  command  in  order  to  show  the  importance  of  the  CRC  and  the  value  it  provides 
(justification  of  funding). 

In  order  to  incentivize  private  industry,  different  approaches  should  be  used  by 
the  DoD.  Private  industry  would  arguably  be  incentivized  the  most  through  increased 
profits.  The  CRC  would  provide  industry  with  access  to  all  requirements  generated 
within  the  DoD.  This  access  would  allow  industry  to  market  their  products  to  target 
audiences  who  would  likely  buy  their  products.  Also,  industry  would  make  more  money 
through  this  enterprise  approach  because  organizations  and  departments  within  the  DoD 
that  would  normally  procure  products  separately  would  now  all  be  targeted  at  a  larger 
level  because  the  CRC  would  connect  their  similar  requirements.  Industry  could  then  sell 
more  products  across  the  DoD  instead  of  just  to  small  niche  markets.  Furthennore,  smart 
industry  analysts  with  access  to  requirements  could  theoretically  look  for  trend 
information  and  predict  where  requirements  were  headed  or  leam  how  to  build  their  next 
product.  This  information  would  further  save  industry  money  by  tailoring  its  research 
towards  more  relevant  ideas  instead  of  riskier  ones.  Another  interesting  approach  would 
be  to  monetize  the  entry  of  capabilities  into  the  CRC,  thereby  providing  funding  to 
industry  and  research  institutions  for  their  work. 

Research  institutions  and  academics  would  be  incentivized  to  enter  information 
about  their  low-TRL  concepts  if  they  were  allowed  to  advertise  their  ideas  to  industry  and 
the  federal  government.  Private  industry  leaders  or  federal  government  decision-makers 
looking  for  the  next  good  idea  could  target  a  search  to  find  a  research  lab  or  academic 
institution  that  they  could  fund  and  then  profit  from  later  on.  Research  institutions  and 
academics  would  benefit  because  the  CRC  would  be  providing  them  with  necessary 
funding  for  what  they  are  passionate  about  and  for  what  would  advance  them  in  their 
academic  careers.  Additionally,  research  institutions  and  academics  are  often  faced  with 
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the  challenge  of  converting  ideas  and  concepts  into  final  products  available  to  end  users. 
The  CRC  would  aid  in  bridging  this  gap  by  connecting  the  researchers  with  private 
industry. 

Acquisition  and  budget  professionals  would  be  incentivized  by  the  promise  of  an 
easier  process  that  also  provided  transparency  and  fast  results.  Overall,  the  benefits  could 
be  seen  across  the  cost,  schedule,  and  performance  metrics  tracked  by  the  acquisition 
professionals.  Cost  could  be  minimized  because  there  would  be  a  greater  likelihood  of 
finding  programs  underway,  instead  of  having  to  create  a  new  technology  or  purchasing 
on  multiple  contracts.  The  schedule  would  be  shortened  because  high-TRL  products 
could  be  identified  more  quickly,  and  the  amount  of  data  available  to  the  professionals 
would  shorten  the  time  necessary  to  make  a  decision.  Lastly,  product  performance  would 
increase  based  off  of  feedback  entered  by  different  stakeholders  into  the  CRC  at  different 
points  in  the  acquisition  process.  The  positive  and  negative  feedback  would  show 
acquisition  professionals  how  the  new  products  were  being  received  and  would  provide 
information  on  how  well  industry  was  meeting  the  timelines  agreed  to. 

IA  and  interoperability  organizations  that  establish  policy  and  standards  for  DoD 
acquisitions  would  be  incentivized  because  of  the  opportunity  to  advertise  to  all 
stakeholders.  The  more  stakeholders  build  products  able  to  meet  current  policies  and 
standards,  the  faster  the  acquisition  process  will  become.  Also,  pre-C&A  products  would 
be  searched  for  because  they  would  be  identified  through  the  CRC  and  would  take  less 
time  to  get  into  the  hands  of  the  warfighter. 

All  stakeholders  would  be  incentivized  by  a  common  goal  of  quickly  providing 
warfighters  with  the  latest  technologies,  which  would  save  lives  and  allow  warfighters  to 
accomplish  their  missions.  An  additional  and  more  direct  approach  to  adding  capabilities 
to  the  CRC  would  be  for  the  federal  government  to  require  stakeholder  input  by  law,  such 
as  they  require  industry  to  register  in  the  federal  contractor  database 
(https://www.bpn.gov/ccr/default.aspx)  and  the  Federal  Awardee  Perfonnance  and 
Integrity  Information  System  (FAPIIS;  National  Defense  Authorization  Act  for  Fiscal 
Year  2010,  2009). 
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3.  Security  Risks 

Laws  provide  boundaries  for  information  sharing.  The  Federal  Acquisition 
Regulation  (FAR)  and  the  Defense  Federal  Acquisition  Regulation  System  (DFARS) 
provide  an  interpretation  of  the  laws  governing  federal  and  DoD  acquisitions.  The  FAR 
and  the  DFAR  would  establish  the  rules  for  sharing  information  within  the  CRC. 
Infonnation  already  within  the  CRC  and  information  being  entered  into  the  CRC  would 
be  tagged  to  identify  its  origin  as  well  as  any  caveats  associated  with  the  viewing  of  the 
information.  Additionally,  classified  infonnation  would  be  outside  the  scope  of  the  CRC 
design  presented  in  this  thesis;  another  CRC  for  a  classified  network  would  be  needed 
because  of  the  extra  security  required.  The  classified  CRC  should  be  designed  to  search 
below  its  classification  level  and  to  take  in  all  information. 

The  current  policies  and  laws  for  acquisitions  are  set  up  to  favor  the  federal 
government  as  opposed  to  industry.  Agents  of  the  federal  government  (anyone  within  the 
DoD)  sharing  information  on  the  CRC  would  have  the  most  access  to  infonnation  in  the 
CRC.  However,  the  most  attention  would  need  to  be  paid  to  the  sharing  of  information 
between  private  industries  and  the  CRC.  Competitors  would  have  to  be  restricted  from 
seeing  each  other’s  proprietary  work.  Private  industry  would  still  benefit  from  insight 
into  DoD  research,  individual  requirements,  interoperability,  and  IA  information. 

Access  by  foreign  companies  to  the  CRC  would  be  a  mitigated  security  risk.  The 
DoD  currently  contracts  with  foreign  companies  as  well  as  with  companies  based  in  the 
United  States  that  have  global  workforces.  These  companies  should  not  be  denied  access 
to  the  CRC.  Partnerships  exist  in  industry  and  academia  that  leverage  foreign  technology 
and  knowledge.  Shutting  out  these  partnerships  would  also  shut  out  the  global 
collaboration  between  industry  and  academia. 

Overall,  the  CRC  would  control  information  through  permission  settings  based  on 
who  was  requesting  it.  The  CRC  would  use  redaction  for  information  that  was  protected 
and  would  provide  contact  data  if  it  was  necessary  for  other  stakeholders  to  have  access 
to  the  information. 
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4.  IA/Interoperability 

The  CRC  would  have  a  large  impact  on  the  interoperability  and  IA  C&A  of 
systems  to  be  acquired.  Combining  the  knowledge  of  the  NIST,  the  NSA,  and  the  JITC 
would  provide  stakeholders  with  a  common  location  for  baselines  and  standards.  For 
example,  the  fastest  way  to  acquire  a  widget  is  to  acquire  one  that  is  already  IA  certified 
and  accredited  and  JITC  approved  for  interoperability.  The  CRC  would  contain  all  of 
this  infonnation,  so  the  customer  would  be  able  to  easily  determine  where  the  products 
were  in  the  process  of  interoperability  and  IA  C&A.  The  CRC  could  leverage  efforts 
underway  to  provide  this  capability.  Among  these  efforts  are  the  NIST  Cross  Domain 
Solutions  Office,  the  National  Information  Exchange  Model,  the  DoD  Metadata  Registry, 
and  the  DoD  IT  Standards  Registry.  Individual  efforts  by  organizations  would  benefit 
from  the  CRC’s  sharing  of  information  because  these  organizations  could  leverage  more 
economies  of  scale. 

5.  Transparency  in  Contracting 

The  CRC  would  allow  transparency  for  capabilities  in  the  existing  contracts.  In 
other  words,  if  a  search  for  a  capability  found  an  existing  contract  vehicle  in  a  different 
organization,  but  still  under  the  DoD  umbrella,  it  would  benefit  the  user.  The  user  could, 
in  theory,  work  out  an  agreement  (Military  Interdepartmental  Purchase  Request  funds)  to 
use  the  existing  contract  vehicle  and  to  satisfy  their  own  requirement  in  an  expeditious 
way  because  the  administrative  work  would  have  already  been  done  by  someone  else. 
DoD  Enterprise  licensing  is  a  great  example  of  how  the  entire  DoD  benefits  from  sharing 
a  single  requirement,  such  as  Adobe1'  Connect™,  across  all  Services  (Johnson,  n.d.). 

6.  Added  Benefits 

The  Federal  Technology  Transfer  Act  of  1986  directed  the  DoD  and  Federal 
Laboratories  to  make  a  focused  effort  to  transfer  federal  research  ideas  to  private  industry 
for  the  benefit  of  the  consumer  and  state  and  local  governments.  This  law  has  created 
organizations  (e.g.,  the  National  Technical  Information  Service  and  the  Federal 
Laboratory  Consortium  for  Technology  Transfer)  that  are  responsible  for  ensuring  federal 
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law  is  not  violated  (Federal  Technology  Transfer  Act  of  1986).  The  National  Technical 
Information  Service  functions  as  a  central  point  for  the  collection,  dissemination,  and 
transfer  of  information  on  federal  technologies  and  would  be  part  of  the  CRC  network 
(Department  of  Commerce,  n.d.).  The  CRC  would  be  a  useful  tool  for  these 
organizations  because  it  would  be  proactive  and  would  bridge  private  industry  and  the 
federal  system.  The  CRC  would  reduce  the  time  and  cost  to  transfer  technologies  from 
the  government  to  the  public  through  the  advertisement  of  government  technologies  to 
industry.  The  main  reason  for  the  reduction  in  time  and  cost  would  be  because  the 
database  of  research  ongoing  under  the  DoD  would  be  updated  to  industry  without  the 
researchers  having  to  put  forth  much  effort.  Therefore,  time  and  cost  would  be  reduced 
because  industry  would  have  direct  insight  as  to  what  the  government  is  focusing  on  and, 
therefore,  likely  to  buy  at  a  future  time. 

The  CRC  would  provide  the  ability  to  leverage  more  of  the  scientists  and 
researchers  in  the  Federal  Laboratory  Consortium  (http://www.federallabs.org).  The 
system  could  couple  researchers  who  are  working  on  similar  projects  in  order  to 
encourage  collaboration  across  physical  boundaries.  The  CRC  would  allow  the  DoD  to 
utilize  the  federal  government’s  existing  investment  in  research  and  development  through 
access  to  their  ongoing  infonnation.  Also,  the  CRC  would  be  beneficial  to  the  DoD  and 
the  federal  government  because  there  are  many  instances  in  which  labs  and  research 
institutions  produce  new  widgets  but  fail  to  initialize  and  act  on  a  plan  for  the  adoption 
and  transfer  of  their  new  technology  to  private  industry.  The  CRC  would  connect  the 
REIT  under  development  to  the  users  who  need  it,  facilitating  communication  and 
coordination  between  different  offices  within  the  federal  government  such  as  the  Office 
of  Research  and  Technology  Applications  and  the  National  Science  Foundation. 

Connecting  the  stakeholders  in  the  CRC  would  provide  the  added  benefit  of 
exposing  acquisition  professionals  (customers)  and  requirements  generators  to  subject- 
matter  experts.  This  approach  would  allow  multiple  experts  to  be  questioned  for  a 
consensus-building  effort  instead  of  trusting  a  single  expert  to  decide  the  fate  of  a 
complex  program. 
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The  CRC  should  be  enabled  to  pull  data  from  online  financial  resources  as  well  as 
from  government  resources.  Websites  such  as  Google  Finance 

(http://www.google.com/fmance),  Yahoo  Finance  (http//:www. finance. yahoo. com),  and 
Bloomberg  (http://www.bloomberg.com)  all  have  specific  financial  information  that 
could  be  used  to  help  establish  the  health  and  validity  of  a  company. 

Historical  information  can  sometimes  be  valuable  in  helping  current  and  new 
programs  through  the  acquisition  process.  Categorized  programs  completed  or  underway 
would  be  advertised  to  the  user  in  order  to  show  examples  of  failures  and  successes  for 
the  benefit  of  all  the  stakeholders.  Examples  of  programs  should  also  be  categorized 
using  a  rating  system  to  show  how  good  or  bad  the  acquisition  was  from  the  perspective 
of  the  user  and  the  government.  It  could  also  be  helpful  to  break  down  each  acquisition 
into  the  components  of  the  process  in  order  to  show  the  quality  of  localized  events,  such 
as  “good”  in  IA  but  “bad”  with  interoperability.  These  assessments  are  subjective,  but  if 
they  helped  all  parties  reach  a  common  ground,  then  their  inclusion  would  be  beneficial. 

The  CRC  is  a  new  system  designed  to  decrease  the  time  it  takes  for  REIT  to  go 
through  the  Integrated  Defense  Acquisition,  Technology,  and  Logistics  Life  Cycle 
Management  System.  The  way  this  is  accomplished  is  through  incentivizing  stakeholder 
involvement,  structured  information  sharing,  and  bridging  technologies.  The  CRC  aims 
to  become  the  portal  application  that  leverages  the  rest  of  the  acquisition  resources  and 
technology  throughout  the  DoD. 
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IV.  BARRIERS  TO  ADOPTION 


The  CRC  will  face  technical,  cultural,  and  policy  barriers  that  might  prevent  its 
adoption  by  the  DoD.  Although  these  barriers  exist,  some  of  them  are  slowly  being 
broken  down  by  new  technologies  and  new  ideas.  In  this  chapter,  these  technologies  and 
the  barriers  they  attempt  to  overcome  are  explored.  The  CRC,  like  all  new  technologies, 
will  have  to  overcome  these  barriers  to  adoption. 

Four  technologies  that  are  already  in  use  by  some  commands  within  the  DoD  will 
be  discussed.  The  proposed  technologies  will  directly  improve  the  process  of  IT 
acquisition  as  well  as  the  acquisition  of  all  products  and  services  involving  REIT.  The 
technologies  are  web  portals,  automated  JCIDs,  information  assurance  test  ranges,  and 
financial  software.  The  purpose  of  discussing  these  technologies  is  to  demonstrate  that 
new  concepts  are  not  only  possible  but  also  currently  in  practice  and  already  improving 
defense  acquisition.  The  technologies  described  will  provide  improved  infonnation  and 
knowledge  to  the  CRC. 

A.  TECHNOLOGICAL  BARRIERS 

1.  Portals  and  Adoption 

Commands  should  utilize  web  portal  technology,  such  as  Microsoft  SharePoint, 
instead  of  routing  hard-copy  documents  or  attempting  to  manage  document  changes 
through  e-mail.  Routing,  editing,  and  approving  documents  involved  in  the  acquisition 
process  can  be  accomplished  more  efficiently  through  the  use  of  digitized  documents  on 
a  web  portal  or  similar  technology.  One  important  requirement  of  web  portals  is  the 
security  and  authentication  of  the  documents  and  users.  Secure  systems,  such  as  the 
public  key  infrastructure  (PKI),  and  encrypted  systems  used  by  the  DoD  are  a  necessity. 

Portals  offer  e-mail  or  other  notification  (e.g.,  text  messaging)  of  document  status 
changes  to  stakeholders  in  order  to  speed  the  acquisition  process.  Changes  made  to  a  file 
are  instantaneously  updated  and  tracked  for  all  others  to  see.  Another  important  feature 
of  web  portal  technology  is  the  ability  to  put  time  constraints  on  documents,  forcing  users 
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to  edit  and  approve  them  before  a  deadline.  Document  version  control  is  also  a  key 
aspect  of  web  portals,  especially  when  working  with  large  groups  of  people.  It  is  difficult 
to  maintain  a  master  version  of  a  document  when  everyone  is  coordinating  changes 
through  e-mail.  The  ability  of  web  portals  to  maintain  a  single  version  online  with 
traceability  of  edits  is  important  to  prevent  version  duplicity. 

To  take  version  control  and  web  portals  one  step  forward,  a  new  technology 
called  Google  Wave  allows  multiple  users  to  edit  files  simultaneously,  negating  the 
condition  in  software  that  normally  occurs  when  two  processes  of  execution  depend  on  a 
shared  state.  Using  Google  Wave  also  allows  anyone  to  start  at  the  beginning  of  the 
changes  made  to  a  document  and  walk  through  them  in  linear  fashion  (Google,  2010). 

If  a  command  requires  printed  paper  to  route  documents  for  editing,  validation, 
and  approval,  then  valuable  time  is  wasted  in  the  acquisition  process.  The  CRC  and  other 
technologies  such  as  portals  should  be  incorporated  into  policies  and  procedures  in  order 
to  expedite  all  processing  of  administrative  documents  required  for  the  acquisition  of 
REIT  and,  in  general,  all  products  and  services. 

2.  Automated  JCIDS  or  Semantically  Informed  Dynamic  Engineering  of 
Capabilities  and  Requirements 

Automated  JCIDS  is  a  software  effort  under  development  through 
MARCORSYSCOM’s  Intelligence,  Surveillance,  and  Reconnaissance  Enterprise  to 
demonstrate  an  effective  capacity  to  automate  the  DoD  JCIDS  system.  The  JCIDS 
defines  acquisition  requirements  and  determines  evaluation  criteria  for  DoD  programs, 
and  it  is  a  subpart  of  the  Integrated  Defense  Acquisition,  Technology,  and  Logistics  Life 
Cycle  Management  System.  The  current  JCIDS  is  complex  and  requires  individual  DoD 
organizations  to  produce  and  maintain  capability  development  documents  and  initial 
capability  documents  for  every  program.  These  documents  do  not  show  common 
relationships  between  programs.  Automated  JCIDS  is  also  referred  to  in  the  commercial 
industry  as  Semantically  Informed  Dynamic  Engineering  of  Capabilities  and 
Requirements  Automated  (SIDECAR)  (Lenat  &  Rode,  n.d.).  The  four  main  components 
of  Automated  JCIDS  are  as  follows: 
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•  A  front-end  template.  This  template  follows  a  model  similar  to  TurboTax 
by  providing  a  user-friendly  interface  and  help  features.  The  system 
would  take  input  on  a  new  REIT’s  requirements,  constraints,  and  measures 
of  performance. 

•  A  back-end  database.  This  database  can  be  searched  and  cross-referenced. 
Automated  JCIDS  takes  user  input  and  compares  it  with  the  information  it 
knows  to  create  necessary  documents  such  as  the  capabilities  development 
document.  The  system  continues  to  ask  the  user  questions  in  order  to 
complete  all  of  the  documents  the  system  finds  related  to  the  program. 

•  Back-end  models  and  algorithms.  “Back-end  models  and  algorithms  that 
cross-reference  and  transform  the  various  views  in  the  inventory  to  create 
on-demand  snapshots  of  the  current  state  of  alternatives  and/or 
compliance”  (Lenat  &  Rode,  n.d.). 

•  Multiple  file  formats.  In  order  to  meet  DoD  requirements,  Automated 
JCIDS  generates  all  of  the  required  documents  in  desired  formats. 

The  Automated  JCIDS  takes  the  system  features  to  be  acquired  as  an  input  and 
guides  the  user  through  a  step-by-step  graphical  user  interface  (GUI)  in  order  to  complete 
the  documents  required  for  the  DoD  JCIDS  in  accordance  with  rules  and  regulations. 
The  system  adds  documents  and  asks  additional  questions  based  on  the  input  from  the 
user  and  back-end  rules;  as  a  result,  the  user  is  not  required  to  remember  all  of  the 
documents  and  rules  needed,  or  be  afraid  of  forgetting  one.  The  added  benefit  to  this 
system  is  its  efficiency  and  accuracy  in  filling  out  forms  while  maintaining  focus  on 
content.  Even  when  programmed  correctly,  software  applications  can  make  mistakes — 
but  not  as  many  as  humans  can  make.  The  entire  process  is  guided  and  is,  therefore, 
designed  for  novice-  and  expert-level  acquisition  professionals.  The  expert  users  of  the 
system  have  the  option  to  see  the  original  acquisition  documents  and  directly  edit  them 
instead  of  using  the  GUI. 

The  requirement  of  an  individual  to  know  all  of  the  documents  in  the  JCIDS 
Integrated  Defense  Acquisition,  Technology,  and  Logistics  Life  Cycle  Management 
System  is  a  daunting  task.  To  add  further  complexity,  the  documents  overlap  each  other 
in  the  content  of  the  information  required.  This  redundancy  wastes  users’  time  because 
they  are  required  to  fill  in  the  same  information  multiple  times  throughout  the  process. 
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The  Automated  JCIDS  system  will  identify  these  areas,  request  information  one  time,  and 
fill  in  all  necessary  instances  in  which  this  infonnation  is  required. 

Overall,  the  Automated  JCIDS  software  will  be  a  benefit  to  the  Integrated 
Defense  Acquisition,  Technology,  and  Logistics  Life  Cycle  Management  System  because 
it  is  efficient  and  cuts  down  on  the  time  necessary  to  complete  all  of  the  paperwork 
required  by  the  current  system.  Also,  Automated  JCIDS  simplifies  an  acquisition 
professional’s  job  because  it  does  not  require  the  individual  to  remember  all  of  the  DoD 
statutory  and  regulatory  policies  and  directives. 

3.  Rapid  IA  Testing  and  Accreditation 

In  a  perfect  world,  REIT  software  and  hardware  could  be  tested  on  an  operational 
network  to  verify  IA  certification,  interoperability  accreditation,  and  functional  success. 
Today,  technology  exists  for  organizations  at  the  local  and  enterprise  levels  to  directly 
replicate  their  operational  networks  at  a  lower  cost  than  building  two  duplicate  networks. 
Using  VMware,  servers,  and  packet  and  pipe  replication,  enterprises  can  directly  mirror 
their  operational  network  down  to  all  the  programs  running  on  it  by  using  the  same 
Internet  Protocol  scheme  and  using  an  IA  test  range. 

A  DAA-approved  IA  test  range  could  be  used  to  quickly  certify  and  accredit  new 
REIT  systems  for  IA  and  interoperability.  The  IA  test  range  would  be  faster  than  normal 
because  it  would  allow  private  industry  to  work  on  an  operation-like  network  from  the 
beginning  to  the  end  of  a  product’s  development,  making  it  so  that  the  industry  would  not 
have  to  wait  until  demonstration  times  to  see  if  the  product  would  fail. 

The  use  of  the  test  range  would  give  acquisition  professionals  a  more  accurate 
picture  of  how  the  new  REIT  will  function  on  the  operational  network  without  impacting 
the  operational  network  with  an  outage,  security  risk,  or  added  latency.  The  IA  and 
interoperability  organizations  would  benefit  because  the  systems  produced  would  be 
more  likely  to  meet  all  the  required  standards  and  would  have  been  tested  thoroughly 
instead  of  just  at  baseline  instances  in  time. 
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The  IA  test  range  concept  is  currently  being  used  in  the  DoD  by  some 
organizations  and  is  under  development  for  the  Marine  Corps  by  MARCORSYSCOM. 
The  relatively  low  cost  of  acquiring  this  technology  makes  it  a  viable  solution  to  help 
expedite  IA  and  interoperability  certification  and  accreditation.  Under  the  current 
process,  if  all  the  proper  procedures  are  followed,  then  IA  certification  alone  takes  a 
minimum  of  a  year  and  a  half.  A  well-executed  IA  test  range  could  accomplish  the  IA 
certification  in  months  instead  of  years. 

4.  Rapid  Procurement  Vehicles 

There  are  many  different  software  efforts  underway  as  well  as  in  use  across  the 
DoD  that  create  Quicken-like  financial  software  features  for  the  DoD  according  to  how  it 
budgets  and  executes  spending  within  the  FAR  and  the  DFARS.  The  problem  associated 
with  the  multiple  programs  is  the  lack  of  standards  for  sharing  information  between  the 
distinct  software  solutions.  If  the  software  is  proprietary  and  if  each  organization  in  the 
DoD  uses  a  different  one,  then  it  is  obvious  how  difficult  it  would  be  to  get  an  accurate 
picture  on  a  macro  level.  Additionally,  if  Quicken  (or  something  like  it)  is  not  used,  then 
the  default  alternate  within  the  DoD  is  a  massive  Excel  spreadsheet  or  some  other 
proprietary,  DoD-specific  software.  The  DoD  will  only  be  able  to  execute  its  budget 
efficiently  if  there  is  an  enterprise-level  directive  that  mandates  the  use  of  the  most 
capable  interoperable  software  across  the  DoD. 

Furthermore,  transparency  within  organizational  chains  of  command  is  necessary 
to  fully  execute  the  budget.  If  a  command  is  able  to  better  track  its  budget,  then  it  will 
have  earlier  insight  into  programs  that  are  not  perfonning  and  that  could  possibly  fail  in 
the  future.  Additionally,  at  an  enterprise  level,  a  senior  command  organization  would 
have  instant,  up-to-date  access  to  its  subordinate’s  budget  in  order  to  verify  budget 
appropriations  and  to  move  money,  if  necessary,  due  to  failing  programs  or  new 
requirements.  To  compare  this  to  banking  software  used  in  the  home  such  as  Quicken  or 
to  the  online  variant  called  Mint.com  (http://www.mint.com),  it  would  be  useful  to  tie 
monetary  transactions  in  and  out  of  the  treasury  account  to  automatically  update  the 
QuickenGov  software. 
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One  simple  proposal  is  to  hire  Intuit,  the  maker  of  Quicken,  to  produce  software 
for  the  DoD  and  for  the  federal  government.  Quicken  is  arguably  the  commercial 
company  with  the  most  talent  in  financial  software,  now  that  Microsoft  has  cancelled  its 
Microsoft  Money  software.  After  the  software  is  developed,  it  could  be  integrated  in  the 
policies  and  procedures  of  the  DoD.  The  end  state  of  this  integration  would  be  a  full, 
detailed  budget  report  for  Congress  at  the  push  of  a  button. 

5.  Classification 

Manually  classifying  all  current,  new,  and  old  DoD  programs  by  capabilities  and 
by  topic  and  subtopics  would  be  an  overwhelming  task.  Therefore,  an  automated 
classification  approach  should  be  used.  Through  classification  of  old  documents,  the 
CRC  would  leverage  the  legacy  systems  in  existence. 

The  best  current  technology  in  automated  classification  is  Statistical  Machine 
Learning  (SML;  http://sml.nicta.com.au).  The  benefit  to  using  SML  is  the  extra  steps  it 
would  allow  a  system  to  take  to  improve  the  accuracy  of  its  classification  and  searching 
of  acquisition  documents.  Document  classification  is  easier  in  the  case  of  acquisitions 
because  the  forms  are  more  structured.  In  the  following  subsections,  some  example 
approaches  for  improving  the  accuracy  of  classification  and  searching  are  presented. 

a.  Validated  Documents 

The  best  approach  to  increasing  SML  accuracy  is  to  provide  the  CRC  with 
validated  documents  from  which  to  leam.  Validated  documents  are  those  that  have  been 
approved  by  acquisition  professionals  in  content  and  format.  Additionally,  the  DoD 
acquisition  professionals  who  are  most  experienced  should  validate  the  best 
requirements,  acquisition,  and  budget  documents  currently  available  by  category  and  use 
them  to  start  the  learning  process  of  SML.  It  is  better  to  use  a  few  validated  documents 
than  to  use  multiple  documents  that  have  been  incorrectly  completed. 
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b. 


Online  Resources 


The  CRC  could  add  a  large  amount  of  information  to  its  knowledge  base 
from  other  online  resources  through  its  push-pull  capability  and  from  SML.  As  data  is 
pulled  into  the  CRC,  it  could  be  put  through  the  SML  filter  to  add  information  and  raw 
data  to  the  CRC  knowledge  base;  it  would  not  save  all  information,  only  the  metadata  and 
information  needed  for  the  CRC  to  know  where  to  go  when  information  is  required. 

c.  Human  Involvement 

No  SML  system  is  perfect.  In  order  to  provide  more  accurate  results, 
humans  should  be  involved  in  randomly  looking  over  the  classification  done  using  the 
SML.  In  addition  to  human  verification,  it  would  be  important  to  allow  all  stakeholders 
to  provide  feedback  to  the  system  to  make  it  more  accurate.  Two  examples  of  the  use  of 
this  method  in  private  industry  are  Pandora  Internet  Radio  (http://www.pandora.com)  and 
Amazon.com  (http://www.amazon.com).  Both  companies  provide  feedback  mechanisms 
to  make  their  applications  stronger  in  providing  better  music  results  or  a  better  shopping 
experience,  respectively.  Pandora  offers  a  simple  “thumbs  up”  or  “thumbs  down” 
feedback  system,  which  allows  its  algorithms  to  learn  whether  the  song  suggested  by  the 
system  matches  what  the  user  likes  or  originally  asked  for.  The  Amazon.com  feedback 
system  allows  a  user  to  rate  products  through  a  star  system  and  text  input.  This 
information  is  then  associated  with  the  user’s  account  and  run  through  the  system’s 
algorithms,  which  then  make  suggestions  about  other  products  the  user  might  like  to 
purchase.  These  two  examples  demonstrate  how  both  the  enterprise  system  and  the  user 
benefit  from  feedback  systems.  The  CRC  should  employ  the  concept  of  a  feedback 
system  in  order  to  maintain  search  accuracy. 

d.  Additional  Feedback 

All  systems  that  interact  with  people  should  learn  from  their  users’ 
actions.  A  powerful  feedback  input  to  the  CRC  would  be  from  the  end  user,  or  the 
warfighter.  The  warfighter  would  provide  input  on  actual  systems  that  were  fielded  or 
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under  development.  This  input  would  give  direct  feedback  to  industry  for  product 
improvement  and  would  also  tell  the  acquisition  professionals  where  to  focus  their 
spending. 

Feedback  from  the  warfighter  would  be  extremely  important,  but  feedback 
from  more  than  just  the  warfighter  would  be  necessary  in  order  to  make  a  better  CRC. 
The  stakeholders  should  also  be  able  to  rate  each  other’s  products,  processes,  and 
abilities.  The  companies  that  receive  justified  negative  feedback  should  quickly  be 
identified  to  the  acquisition  professionals  and,  in  theory,  lose  business.  A  simple  star 
rating  with  the  option  of  adding  amplifying  text  could  be  used  to  rank  many  aspects  of 
the  CRC.  Amazon.com  (http://www.amazon.com)  is  an  example  of  a  company  that  is  an 
industry  expert  in  this  field. 

6.  Technology  Barrier  Overview 

One  policy  required  throughout  all  of  the  technologies  listed  in  the  previous 
subsection  is  the  need  to  authenticate  and  validate  who  is  on  the  CRC  and  who  is  making 
changes  to  it.  Therefore,  in  addition  to  the  technologies  listed,  it  is  important  to 
incorporate  the  DoD  CAC  procedures  using  PKI. 

Again,  technologies  do  not  provide  all  of  the  answers  for  fixing  the  Integrated 
Defense  Acquisition,  Technology,  and  Logistics  Life  Cycle  Management  System. 
However,  they  do  provide  solutions  to  solve  some  of  the  problems  within  the  system. 
The  technologies  listed  in  this  chapter  have  all  been  developed  for  use  commercially  or 
for  the  federal  government  specifically  and  have  shown  success  in  their  results.  The  DoD 
should  adopt  and  invest  in  as  many  of  these  successes  as  possible. 

Outside  of  the  technology  barriers  the  CRC  will  face  in  its  adoption,  there  are 
additional  cultural  barriers  that  will  pose  more  of  a  challenge  to  its  adoption.  Human 
behavior  is  a  difficult  field  of  study  because  there  are  many  intangible  aspects.  The  CRC 
will  face  a  DoD  culture  steeped  in  tradition  and  a  stereotypical  lack  of  innovative 
thinking. 
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B.  CULTURAL  BARRIERS 

Across  the  DoD  there  are  many  different  cultures  involved  in  the  acquisition  of 
REIT.  In  this  author’s  opinion,  the  cultural  barriers  to  adoption  involve  the  emotions  of 
individuals,  power  struggles,  and  self-importance.  The  CRC  and  other  technologies 
discussed  in  this  chapter  are  technologically  possible  or  already  in  use  by  consumers 
today.  However,  just  because  the  technologies  are  possible  does  not  mean  that  the 
cultural  barriers  they  will  face  for  entry  into  the  DoD  will  be  easy.  Longstanding  cultural 
attitudes  and  beliefs  within  the  DoD,  such  as  group  think,  make  it  difficult  for  individuals 
to  embrace  new  ideas  and  methods  for  solving  problems  (Hewson,  2005).  The  defense 
acquisition  culture  has  increasingly  been  tied  down  by  bureaucratic  requirements,  self- 
imposed  and  external,  that  have  led  the  culture  to  become  one  with  the  status  quo. 

Cultural  barriers  will  need  to  be  broken  in  order  for  acquisition  professionals  to 
embrace  the  new  concept  of  the  CRC  and  the  benefits  it  will  bring  to  defense  acquisition. 
The  CRC’s  initial  success  will  require  funding,  research,  policy  changes,  and  a  product 
demonstration.  In  this  author’s  opinion,  these  components,  along  with  the  CRC  concept, 
will  lead  to  a  successful  project  start. 

1.  Eighty  Percent  Versus  One  Hundred  Percent  Mentality 

The  nature  of  the  work  the  DoD  is  involved  in  has  created  a  culture  of  zero  failure 
(100%  solution)  and  perfection  with  regard  to  the  requirements  set  for  systems,  services, 
and  equipment.  This  cultural  nonn  is  justified  in  many  cases;  however,  it  cannot  be 
justified  in  all  cases  of  REIT.  This  mentality  is  a  barrier  to  the  CRC  and  to  acquiring 
REIT  because  it  does  not  allow  for  evolutionary  development,  which  is  based  on  the 
principle  of  developing  solutions  through  improvements  iteratively  (80%  solution), 
possibly  never  reaching  a  100%  solution.  Most  people  look  at  zero  failure  in  the  wrong 
way:  failure  is  either  optimal  or  epic.  An  epic  failure  is  one  that  wastes  large  sums  of 
money  and  provides  no  feedback  to  the  system.  An  optimal  failure  is  one  that  does  not 
waste  a  lot  of  money  and  provides  constructive  feedback  to  the  system.  Optimal  failure 
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is  obviously  desired.  However,  failure  itself  is  a  tough  concept  for  most  people, 
especially  within  the  DoD,  to  accept.  The  CRC  would  show  the  benefits  of  both  the  80% 
and  100%  solutions  by  providing  in-depth  background  information  and  analyses. 
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V.  EXECUTION 


In  this  chapter,  some  steps  that  could  help  Collective  Acquisition  get  traction 
within  the  DoD  or  federal  government  are  described.  One  of  the  early  keys  will  be 
finding  both  civilian  and  military  champions  of  the  process  who  can  effectively  market  it. 
A  prototype  CRC  would  help  in  this  regard,  but  without  major  funding  up  front  to 
develop  a  nontrivial  prototype,  marketing  could  prove  difficult.  As  a  result,  it  is  essential 
that  proponents  of  the  idea  secure  some  initial  funding  for  it. 

It  will  be  necessary  at  the  Senior  Executive  Service  (SES)  to  have  a  proponent 
who  controls  funding  and  can  influence  policy.  For  this  reason,  it  will  be  necessary  to 
have  a  three-  or  four-star  flag  officer  on  the  Joint  Staff  and  one  of  the  Under  Secretaries 
of  Defense  who  support  the  CRC.  This  senior  top  cover  will  be  necessary  because  such 
leaders  can  override  the  cultural  barriers  the  CRC  will  face  as  a  new  concept  that 
challenges  the  normal  way  of  doing  business.  Lower-level  civilian  and  military 
operational  champions  will  be  necessary  because  they  will  fully  understand  all  of  the 
complexities  of  the  CRC  and  will  be  able  to  explain  them  in  a  nontechnical  way.  It  will 
be  important  to  have  as  many  senior  and  junior  military  and  civilian  operational 
champions  from  the  original  stakeholder  list  as  possible.  Among  them  are  the  following: 

•  Requirements  generators, 

•  Private  industry, 

•  Government  research  labs  and  institutions, 

•  Acquisition  professionals, 

•  Budget  professionals, 

•  IA  organizations  and  policy-makers,  and 

•  Interoperability  organizations. 

The  more  stakeholder  involvement,  the  easier  it  will  be  to  justify  the  CRC.  It  is 
also  important  to  note  that  voluntary  involvement  in  the  project  will  provide  an  important 
foundation  of  information  to  the  CRC.  If  a  stakeholder  cannot  be  convinced  to 
voluntarily  contribute  to  the  CRC,  then  this  would  likely  demonstrate  to  others  a  lack  of 
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confidence  in  the  system,  resulting  in  the  failure  of  the  program  itself.  The  CRC  could  be 
viewed  as  a  threat  to  jobs  and  the  status  quo;  therefore,  the  lower-level  champions  will  be 
essential  for  explaining  the  CRC  in  nonthreatening  terms  to  those  who  feel  the  system 
threatens  their  jobs.  This  will  be  necessary  in  order  to  gain  their  support  and  demonstrate 
the  benefits  of  the  CRC. 

A.  PROOF  OF  CONCEPT 

The  initial  cultural  barriers  to  entry  that  the  CRC  will  face  can  be  mitigated 
through  the  use  of  the  operational  champions.  However,  this  is  only  a  temporary  solution 
and  will  not  provide  all  the  necessary  components  nor  funding  to  the  CRC.  In  order  for 
the  CRC  to  reach  its  full  potential,  it  will  need  to  be  championed  at  the  federal  level  and 
at  the  commercial-industry  level,  both  of  which  provide  products  and  services  to  the 
DoD.  In  an  ideal  situation,  the  initial  operational  champions  will  have  provided  enough 
research,  funding,  and  top  cover  for  a  significant  prototype  to  be  built.  The  CRC 
prototype,  in  combination  with  the  senior  operational  champions,  is  necessary  to 
convince  other  noninnovators  of  its  necessity  and  positive  evolutionary  impact. 

To  succeed,  it  will  be  necessary  for  Congress  to  appropriate  adequate  funding  to 
the  CRC,  but,  more  important,  Congress  will  need  to  require  by  law  that  industry  and  the 
federal  government  provide  the  necessary  input  to  the  CRC.  This  requirement  will  be 
necessary  because  the  stakeholders  will  not  all  voluntarily  participate  in  the  project.  The 
inclusion  of  all  of  the  initial  stakeholders  is  important  because  the  CRC  will  not  reach  its 
full  potential  without  them. 

Congress  will  not  be  hard  to  convince  of  the  benefits  as  long  as  a  CRC  proof  of 
concept  can  be  demonstrated  to  streamline  the  efficiency  of  defense  acquisition,  cut  out 
waste,  save  money,  and  provide  incentives  to  small  and  large  businesses  for  jobs  to  their 
constituents.  The  perfect  CRC  demonstration  would  include  the  acquisition  scenario 
listed  in  Chapter  I  and  a  background  visualization  of  the  cross-domain  resources  the  CRC 
was  able  to  bridge  in  order  to  come  to  its  recommendations.  This  would  not  be  a  new 
concept  for  Congress  since  they  have  made  laws  in  the  past  requiring  the  DoD  and 
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industry  to  comply  with  new  concepts  (e.g.,  industry  registration  in  a  contractor 
database).  Congress  carries  a  “big  stick”  when  it  comes  to  industry  involvement  because 
they  can  withhold  income  from  companies  that  do  not  comply  with  their  mandates. 
Ideally,  every  stakeholder  will  voluntarily  comply  with  the  CRC  because  of  the 
incentives  and  evolutionary  benefits  it  will  provide.  Congress  will  be  helpful  in 
persuading  the  members  of  industry  and  the  federal  government  who  do  not  want  to  lose 
their  stovepipes  of  profit  and  power.  Another  simple  example  would  be  for  the  CRC  to 
show  waste  in  the  defense  acquisition  system  by  identifying  two  organizations  (e.g.,  the 
Navy  and  the  Marines)  that  are  about  to  purchase  nearly  the  exact  same  product  or 
service.  The  CRC  would  proactively  show  the  waste  and  provide  more  information  about 
the  two  companies  from  which  the  Services  intend  to  make  a  purchase.  In  the  same 
manner,  the  CRC  could  expose  corrupt  companies  that  are  trying  to  double  dip  and  sell 
the  same  product  to  the  government  under  two  different  contracts. 

It  is  important  to  demonstrate  the  initial  capability  of  the  CRC  to  Congress  and 
others  in  order  to  gain  constructive  feedback  and  prove  that  money  is  being  spent  wisely. 
The  evolutionary  way  in  which  the  CRC  will  be  developed  should  also  produce 
demonstrations  at  the  end  of  each  iteration.  By  demonstrating  continued  success  and 
management  of  expectations,  the  DoD  will  gain  more  support  for  the  CRC. 

B.  INDUSTRY  ACCEPTANCE 

Federal  government  stakeholders  are  the  most  likely  to  participate  because  they 
are  governed  by  federal  law.  Private  industry  is  a  different  story.  In  this  author’s 
opinion,  although  private  industry  is  obligated  to  obey  the  laws  of  Congress,  they  have 
more  money  and  lawyers  to  fight  new  concepts  when  faced  with  competition.  The 
incentives  discussed  in  Chapter  III  will  ideally  bring  private  industry  to  understand  the 
CRC  opportunities  because  they  will  feel  the  benefit  from  the  CRC.  In  order  to  minimize 
noncompliance  and  grow  rapid  support  within  industry,  it  will  be  important  to  design  the 
CRC  to  be  as  open,  secure,  and  user-friendly  as  possible.  The  CRC  human  computer 
interface  should  be  thoroughly  tested.  The  easier  and  more  automated  the  system  is,  the 
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less  likely  there  will  be  resistance  from  the  stakeholders.  In  the  end,  it  is  all  about 
making  the  CRC  a  positive  experience  by  making  it  nearly  effortless  for  stakeholders  to 
participate  in  the  CRC  interface. 

C.  OVERCOMING  DEMOTIVATION 

People  are  the  most  important  asset  of  the  DoD,  and  they  are  crucial  in 
performing  the  tasks  required  by  the  defense  acquisition  system  for  new  projects.  In  this 
author’s  opinion,  people  can  be  further  grouped  into  categories  of  motivators  or 
demotivators.  A  motivator  will  always  maintain  an  open  mind  with  regard  to  new 
concepts,  work  hard  at  what  they  do,  and,  in  general,  see  the  big  picture  when  it  comes  to 
acquisitions.  Unfortunately,  the  DoD  is  also  full  of  demotivators.  Demotivators  could  be 
good  at  what  they  do,  but,  in  general,  “no”  is  their  first  answer  to  anything  outside  the 
norm  or  to  anything  that  could  possibly  put  them  out  of  a  job  or  require  them  to  do  work 
they  are  not  used  to  doing.  The  CRC  will  face  the  demotivators  at  the  peak  of  their 
demotivation  because  the  CRC  will  threaten  the  nonnal  way  of  business  and  could  be 
seen  as  an  attempt  to  automate  human  involvement  in  defense  acquisition.  For  this 
reason,  it  will  be  crucial  to  identify  the  demotivators  as  early  as  possible  and  to  detennine 
the  best  way  to  work  around  or  replace  them.  These  individuals  should  not  immediately 
be  dismissed  because  they  possess  core  knowledge  about  who  can  get  things  done  when 
needed.  The  CRC  will  aim  to  help  these  individuals  be  more  efficient  and  streamline 
their  work,  potentially  turning  them  into  motivators.  The  CRC  will  provide  a 
collaborative  environment  full  of  motivators  and  other  experts  that  will  allow  users  to 
easily  bypass  the  demotivators.  The  other  important  combatants  in  the  fight  against 
demotivators  are  the  senior  operational  champions.  The  benefit  of  being  a  senior  leader 
in  a  vertical  organization  is  having  the  ability  to  defeat  demotivators  through  orders, 
reasoning,  or  removal  from  projects.  These  senior  leaders  will  be  necessary  in  order  to 
convince  others  that  the  CRC  is  an  important  evolutionary  step  in  the  future  of 
acquisitions. 
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D.  FOCUS  ON  EMOTION 


In  this  author’s  opinion,  the  one  commonality  across  the  federal  government  with 
regard  to  defense  acquisition  is  the  deep  feeling  (i.e.,  frustration)  that  work  could  be  done 
more  efficiently  and  could  produce  better  results.  This  feeling,  evoked  when  anyone 
within  the  DoD  is  asked  about  the  acquisition  system,  could  be  used  as  a  strong  enabler 
for  the  CRC.  The  feeling  of  frustration  stirred  by  the  acquisition  system  can  partly  be 
mitigated  with  the  use  of  technology.  The  criterion  for  mitigation  is  adoption  of  the 
technology  into  the  normal  operations  of  the  acquisition  system  and  the  simplicity  of  that 
technology.  In  this  author’s  opinion,  people  are  most  likely  to  try  something  new  when 
they  are  extremely  disappointed  with  the  current  system. 

As  discussed  in  Chapter  IV,  feedback  is  an  important  aspect  of  the  acquisition 
process  because  it  gives  individuals  a  sense  of  importance  and  provides  valuable 
information  to  the  CRC.  The  feedback  from  seeing  direct  results  based  on  an  individual 
input  is  an  important  feature  that  the  CRC  will  provide.  The  feedback  within  the  CRC 
could  make  a  contribution  to  a  cause  that  an  individual  knows  will  help  him  or  her  save  a 
life  in  the  future,  such  as  a  recommendation  for  changing  the  design  of  a  critical  piece  of 
communications  equipment. 

E.  OPERATIONAL  COMMAND  INVOLVEMENT 

The  operational  commander  should  be  involved  in  the  process  for  acquiring 
technology  relevant  to  his  or  her  mission.  This  involvement  would  provide  a  commander 
with  the  means  of  making  the  decision  on  the  value  of  bringing  in  an  early  technology 
with  the  80%  solution,  as  long  as  he  or  she  made  the  decision  knowing  the  associated 
risks.  Furthermore,  commanders  would  provide  direct  feedback  into  the  decision  cycle, 
which  would  benefit  future  iterations  of  the  REIT  and  provide  feedback  to  the  DoD  about 
whether  the  80%  is  a  quality  REIT  or  whether  it  does  not  meet  the  requirements.  The 
CRC  would  stay  involved  throughout  the  entirety  of  this  process  and  would  provide  the 
operational  commander  with  extra  resources  (e.g.,  subject-matter  experts). 


39 


F.  ACCOMMODATING 

Initially,  the  CRC  would  not  replace  any  systems;  therefore,  it  would  not  threaten 
any  powerful  stovepipes  existing  in  the  federal  government.  If  people  are  made  to  feel 
that  their  power  base  will  gain  importance  rather  than  be  threatened,  then  they  will  be 
more  likely  to  support  aspects  of  the  CRC.  An  effort  should  be  made  to  brand  the  CRC 
as  a  third-party  application  that  would  not  take  money  or  resources  away  from  any 
program,  but  rather  enhance  what  is  already  underway.  In  the  future,  if  the  online 
resources  were  found  to  be  more  efficient  under  the  CRC  umbrella,  then  the  system 
would  be  made  open  enough  to  envelope  them,  but  this  decision  would  be  made  by  future 
policy-makers. 

G.  DEFENSE  ACQUISITION  UNIVERSITY 

In  addition  to  showing  a  prototype  CRC  and  explaining  the  value  the  CRC  will 
bring,  an  important  emphasis  should  be  made  with  regard  to  the  Joint  Forces  going 
through  DAU  training  and  certification.  Because  students  are  impressionable,  they 
represent  the  easiest  way  to  spread  information  when  they  enter  the  workforce.  Students 
would  easily  adopt  the  CRC  as  a  new  concept  and  would  continue  to  provide  momentum 
for  the  CRC  project. 
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VI.  SUMMARY  AND  FUTURE  WORK 


A.  SUMMARY 

The  DoD  is  burdened  by  an  Integrated  Defense  Acquisition,  Technology,  and 
Logistics  Life  Cycle  Management  System  that  is  designed  to  acquire  large  systems,  such 
as  ships,  and  that  takes  years  to  complete.  Information  technology  evolves  at  a  rapid 
pace  because  it  is  driven  by  industry.  The  DoD  acquisition  system  is  therefore  at  odds 
with  industry  development,  at  least  with  respect  to  information  technology.  The 
acquisition  of  information  technology  cannot  follow  the  same  path  as  a  ship  if  the  DoD 
wants  the  warfighter  to  have  the  most  advanced  technologies. 

The  current  acquisition  process  is  burdened  with  many  obstacles.  It  is  an  artifact 
of  an  industrial-military  alliance  that  has  evolved  over  many  years.  As  such,  it  is  riddled 
with  special  provisions,  regulations,  directives,  best  business  practices,  etc.,  that  have 
become  a  veritable  mine  field  to  navigate.  Other  obstacles  include  a  DoD  culture  and 
larger  political  enviromnent  that  together  add  multiple  layers  of  bureaucracy  and 
uncertainty  to  the  process.  It  is  unrealistic  to  expect  a  clean  slate  in  order  to  begin 
designing  a  totally  new  process.  Realistically,  as  much  current  practice  as  possible  has  to 
be  incorporated  in  order  to  make  any  real  progress.  To  understand  what  incorporation 
means,  current  practice  needs  to  be  understood — not  at  the  level  of  published  procedures, 
but  rather  at  the  level  of  the  trenches  or  frontlines  where  real  acquisition  decisions  are 
made  today.  To  that  end,  the  author  embedded  himself  in  three  system  commands  over  a 
period  of  12  months  to  observe  operations.  The  author  observed  several  areas  in  which 
improvements  are  needed,  among  them  are  policy,  laws,  education,  and  culture.  This 
thesis  recommended  changes  that  should  occur  in  the  acquisition  process  for  the  types  of 
technology  that  evolve  very  quickly. 

One  of  the  changes  that  needs  to  occur  is  the  sharing  of  information  about  a 
variety  of  things.  The  acquisition  of  technology  is  about  much  more  than  the  technology 
alone.  Each  stage  of  the  acquisition  process,  even  for  technologies  that  are  never 
ultimately  adopted,  offers  some  information  that  needs  to  be  cataloged  in  a  way  that 
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makes  it  useful  to  others.  This  thesis  proposed  a  clearinghouse  for  this  purpose,  called 
the  Capabilities  and  Requirements  Clearinghouse  (CRC).  The  CRC  would  decrease  the 
amount  of  time  required  to  get  information  technology  to  the  warfighter.  It  would  do  so 
by  relating  existing  resources,  automatically  crawling  through  data,  and  providing  a 
single  source  of  information  for  all  aspects  of  acquisition.  The  DoD  loses  some  of  its 
ability  to  acquire  infonnation  technology  because  economies  of  scale  are  not  maximized 
through  the  relationship  of  program  information.  The  lack  of  relationships  between 
online  resources  and  databases  causes  many  steps  to  be  repeated.  Going  forward,  it  will 
be  unacceptable  to  maintain  stovepipes  of  web  resources.  Instead,  the  online  resources 
will  need  to  be  integrated,  and  the  CRC  provides  a  framework  for  accomplishing  this. 

The  changes  that  need  to  occur  are  not  limited  to  information  sharing.  Although 
that  is  a  central  component,  other  barriers  must  be  overcome.  These  barriers  are  in  the 
following  areas: 

•  Certification  and  accreditation, 

•  Budgeting  flexibility, 

•  Testing  and  validation,  and 

•  Cultural  hurdles. 

Currently,  certification  and  accreditation  involve  many  parties,  such  as  the  NIST, 
the  NSA,  a  Service’s  DAA,  and  so  on.  The  process  produces  artifacts  such  as  FIPS 
certificates  and  test  suites  within  which  products  are  certified.  These  artifacts  may  be 
used  in  the  certification  of  new  products.  For  instance,  a  cryptographic  module’s 
certificate  may  be  reused  to  certify  another  product  if  that  product  uses  the  same  module. 
How  do  we  know  which  module  was  used?  How  do  we  know  in  which  environment  the 
module  was  tested?  The  answers  to  these  questions  would  be  available  through  the  CRC, 
which  would  catalog  infonnation  along  many  different  axes. 

The  DoD’s  Planning,  Programming,  Budgeting,  and  Execution  process  is  not 
transparent  or  flexible  enough  to  accommodate  the  pace  at  which  infonnation  technology 
evolves.  In  order  to  improve  this,  a  Quicken-like  software  package  is  recommended. 
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The  package  should  be  mandated  DoD-wide  in  order  to  share  budget  information  across 
the  Services  and  to  provide  greater  visibility  into  budget  issues.  This  way,  budget 
problems  will  be  revealed  earlier. 

As  far  as  testing  and  validation  is  concerned,  relatively  fewer  changes  seem  to  be 
needed.  The  reason  is  the  IA  test  range  already  provides  a  configurable  network  test 
environment  to  facilitate  testing.  It  appears  that  one  of  the  major  shortcomings  of  the 
range  is  its  ability  to  interface  with  other  data  repositories  like  the  CRC.  For  instance, 
knowing  the  exact  configuration  cataloged  by  a  vendor  would  allow  a  DAA  to  more 
quickly  compare  products  from  different  vendors  because  knowing  the  configuration 
would  level  the  playing  field. 

The  cultural  hurdles  will  be  more  difficult  to  overcome  and  will  require  decision¬ 
makers  to  improve  the  system  by  evaluating  and  merging  current  DoD  acquisition  rules. 
Removing  duplicate  rules  and  requirements  that  require  extra  work  will  be  the  fastest 
way  to  improve  the  acquisition  system.  In  addition,  the  cultural  belief  that  80% 
perfection  is  a  failure  needs  to  be  better  explained  with  regard  to  information  technology. 
An  iterative  process  that  produces  only  an  80%  solution  is  often  adequate.  Some 
professionals  find  this  difficult  to  accept  and  need  to  adapt. 

B.  FUTURE  WORK 

In  order  to  execute  the  CRC,  a  significant  amount  of  effort  will  be  necessary  to 
build,  validate,  and  test  the  conceptual  idea.  Additionally,  work  will  need  to  be  done  to 
relate  the  online  resources  and  explore  the  technologies  discussed  in  this  thesis.  The  goal 
of  future  work  should  be  to  improve  on  the  foundation  presented  in  this  thesis  and 
produce  a  CRC  prototype. 

The  CRC  will  most  importantly  need  both  DoD  and  congressional  champions  in 
order  to  be  successful.  These  champions  should  make  efforts  to  rally  for  support  of  the 
CRC  in  their  respective  organizations  and  push  for  consolidation  of  resources.  In 
addition,  effort  will  be  necessary  to  motivate  others  to  review  current  and  past  policies, 
laws,  and  rules  in  order  to  simplify  and  streamline  them.  These  will  have  a  direct, 
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positive  impact  on  the  CRC.  Within  the  DoD,  the  first  champion  should  be  the  Defense 
Advanced  Research  Projects  Agency  (DARPA)  and  the  Office  of  the  Under  Secretary  of 
Defense  for  Acquisition,  Technology,  and  Logistics.  These  organizations  have  the 
money,  resources,  and  expertise  to  nurture  the  CRC.  It  is  key  to  get  initial  validation,  or 
a  toehold,  by  an  agency  actually  acquiring  information  technology.  An  example  of  such 
an  agency  is  the  Defense  Information  Systems  Agency  (DISA). 

Current  federal  laws  and  DoD  policy  documents  dictate  the  rules  for  who,  what, 
when,  where,  why,  and  how  an  individual,  company,  or  organization  can  share 
information  within  and  outside  the  DoD  and  federal  government.  The  number  of 
documents,  policies,  laws,  rules,  etc.,  is  far  too  great  for  any  one  person  to  master.  These 
rules  will  need  to  be  codified  and  represented  within  the  CRC  so  that  no  violations  occur. 
Therefore,  research  will  need  to  be  done  to  create  a  database  of  all  rules  and  their 
dependencies  and  to  represent  them  in  the  CRC. 

The  list  of  online  resources  in  Appendix  D  is  a  very  brief  list  of  what  is  available 
to  the  DoD  and  federal  acquisition  communities.  Research  is  needed  to  identify  all  of  the 
additional  websites  and  databases  that  will  need  to  be  identified  in  order  to  relate  or 
consolidate  resources.  The  overlap  of  resources  is  a  key  area  of  study  that  needs 
attention.  Additionally,  the  information  and  data  contained  in  the  identified  resources 
will  need  to  be  organized  and  plugged  into  the  CRC  so  that  it  may  serve  as  the  front  end 
to  these  resources.  Further  research  is  required  in  the  categorization  of  the  information 
and  data  using  SML,  as  discussed  in  this  thesis. 

Further  research  is  needed  to  identify  how  technologies  such  as  the  proposed 
QuickenGov  and  Automated  JCIDS  would  relate  to  the  CRC  and  other  new  resources 
identified.  Specifically,  research  into  technology  and  the  level  at  which  it  is  interoperable 
with  the  CRC  will  need  to  be  identified. 

In  Chapter  V,  the  many  issues  that  the  CRC  will  face  with  regard  to  social  science 
were  discussed.  Further  research  is  needed  to  study  how  the  CRC  will  impact  the 
emotions  of  DoD  personnel.  Also,  more  research  is  required  as  to  how  human  emotions 

by  personnel  in  the  DoD  will  impact  and  drive  the  CRC. 
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As  much  as  possible,  all  aspects  of  the  CRC  should  be  kept  at  an  unclassified 
level.  However,  if  a  higher  classification  of  the  CRC  is  needed,  then  it  should  be 
carefully  engineered  with  the  ability  to  cross  enterprise  domains  in  order  to  pull 
information.  Research  will  be  needed  to  detennine  how  to  set  up  this  relationship 
between  software  programs  on  different  domains  as  well  as  how  to  control  multilevel 
access  to  infonnation. 
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APPENDIX  A.  HARDWARE  AND  SOFTWARE  TECHNOLOGY 
READINESS  LEVELS  TABLE 


Technology  Readiness  Levels  (TRLs)  are  metrics  used  by  the  DoD  to  determine 
the  maturity  of  rapidly  evolving  technologies.  This  maturity  can  then  help  the  DoD 
determine  the  risk  for  adoption  of  the  technology.  Furthermore,  TRLs  are  a  way  for 
acquisition  professionals  to  estimate  how  much  time  it  will  take  for  a  technology  to  reach 
completion  or  production.  See  Table  1  in  this  appendix  for  a  full  list  of  the  definitions  of 
TRLs  as  defined  by  the  DoD  Technology  Readiness  Assessment  (TRA)  Deskbook 
(2009). 
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Table  1.  Definitions  of  Technology  Readiness  Levels 


Hardware  TRL  Definitions,  Descriptions,  and  Supporting  Information 

Software  TRL  Definitions,  Descriptions,  and  Supporting  Information 

TRL  Definition 

Description 

Supporting  Information 

TRL  Definition 

Description 

Supporting  Information 

1 

Basic  principles 
observed  and 
reported. 

Lowest  level  of  technology  readiness.  Scientific  research  begins  to 
be  translated  into  applied  research  and  development  (R&D).  Exam¬ 
ples  might  include  paper  studies  of  a  technology's  basic  properties. 

Published  research  that  identifies  the  principles  that  underlie  this 
technology.  References  to  who,  where,  when. 

1 

Basic  principles 
observed  and 
reported. 

Lowest  level  of  software  technology  readiness.  A  new  software 
domain  is  being  investigated  by  the  basic  research  community.  This 
level  extends  to  the  development  of  basic  use,  basic  properties  of 
software  architecture,  mathematical  formulations,  and  general 
algorithms. 

Basic  research  activities,  research  articles,  peer-reviewed  white 
papers,  point  papers,  early  lab  model  of  basic  concept  may  be 
useful  for  substantiating  the  TRL. 

2 

Technology 
concept  and/or 
application 
formulated. 

Invention  begins.  Once  basic  principles  are  observed,  practical 
applications  can  be  invented.  Applications  are  speculative,  and 
there  may  be  no  proof  or  detailed  analysis  to  support  the  assump¬ 
tions.  Examples  are  limited  to  analytic  studies. 

Publications  or  other  references  that  outline  the  application  being 
considered  and  that  provide  analysis  to  support  the  concept. 

2 

Technology 
concept  and/or 
application 
formulated. 

Once  basic  principles  are  observed,  practical  applications  can  be 
invented.  Applications  are  speculative,  and  there  may  be  no  proof 
or  detailed  analysis  to  support  the  assumptions.  Examples  are 
limited  to  analytic  studies  using  synthetic  data. 

Applied  research  activities,  analytic  studies,  small  code  units,  and 
papers  comparing  competing  technologies. 

3 

Analytical  and 
expenmental 
critical  function 
and/or  charac¬ 
teristic  proof  of 
concept. 

Active  R&D  is  initiated.  This  includes  analytical  studies  and  labora¬ 
tory  studies  to  physically  validate  the  analytical  predictions  of  sepa¬ 
rate  elements  of  the  technology.  Examples  include  components  that 
are  not  yet  integrated  or  representative. 

Results  of  laboratory  tests  performed  to  measure  parameters  of 
interest  and  comparison  to  analytical  predictions  for  critical  subsys¬ 
tems.  References  to  who,  where,  and  when  these  tests  and  com¬ 
parisons  were  performed. 

3 

Analytical  and 
expenmental 
critical  function 
and/or  charac¬ 
teristic  proof  of 
concept. 

Active  R&D  is  initiated.  The  level  at  which  scientific  feasibility  is 
demonstrated  through  analytical  and  laboratory  studies.  This  level 
extends  to  the  development  of  limited  functionality  environments  to 
validate  critical  properties  and  analytical  predictions  using  non-inte- 
grated  software  components  and  partially  representative  data. 

Algorithms  run  on  a  surrogate  processor  in  a  laboratory  environ¬ 
ment,  instrumented  components  operating  in  a  laboratory  environ¬ 
ment,  laboratory  results  showing  validation  of  critical  properties. 

4 

Component 
and/or  bread¬ 
board  validation 
in  a  laboratory 
environment. 

Basic  technological  components  are  integrated  to  establish  that 
they  will  work  together.  This  is  relatively  "low  fidelity’  compared  with 
the  eventual  system.  Examples  include  integration  of  "ad  hoc" 
hardware  in  the  laboratory. 

System  concepts  that  have  been  considered  and  results  from 
testing  laboratory-scale  breadboard(s)  References  to  who  did  this 
work  and  when.  Provide  an  estimate  of  how  breadboard  hardware 
and  test  results  differ  from  the  expected  system  goals. 

4 

Module  and/or 
subsystem  vali¬ 
dation  in  a 
laboratory  envi¬ 
ronment  (i.e., 
software 
prototype  devel¬ 
opment 
environment). 

Basic  software  components  are  integrated  to  establish  that  they  will 
work  together.  They  are  relatively  primitive  with  regard  to  efficiency 
and  robustness  compared  with  the  eventual  system.  Architecture 
development  initiated  to  include  interoperability,  reliability,  maintain¬ 
ability,  extensibility,  scalability,  and  security  issues.  Emulation  with 
current/legacy  elements  as  appropriate.  Prototypes  developed  to 
demonstrate  different  aspects  of  eventual  system. 

Advanced  technology  development,  stand-alone  prototype  solving  a 
synthetic  full-scale  problem,  or  standalone  prototype  processing 
fully  representative  data  sets. 

5 

Component  and/ 
or  breadboard 
validation  in  a 
relevant 
environment. 

Fidelity  of  breadboard  technology  increases  significantly.  The  basic 
technological  components  are  integrated  with  reasonably  realistic 
supporting  elements  so  they  can  be  tested  in  a  simulated  environ¬ 
ment.  Examples  include  “high-fidelity"  laboratory  integration  of 
components. 

Results  from  testing  a  laboratory  breadboard  system  are  integrated 
with  other  supporting  elements  in  a  simulated  operational  environ¬ 
ment.  How  does  the  “relevant  environment"  differ  from  the  expected 
operational  environment?  How  do  the  test  results  compare  with 
expectations?  What  problems,  if  any,  were  encountered?  Was  the 
breadboard  system  refined  to  more  nearly  match  the  expected  sys¬ 
tem  goals? 

5 

Module  and/or 
subsystem  vali¬ 
dation  in  a 
relevant 
environment. 

Level  at  which  software  technology  is  ready  to  start  integration  with 
existing  systems.  The  prototype  implementations  conform  to  target 
environment/interfaces.  Experiments  with  realistic  problems.  Simu¬ 
lated  interfaces  to  existing  systems.  System  software  architecture 
established.  Algorithms  run  on  a  processor(s)  with  characteristics 
expected  in  the  operational  environment. 

System  architecture  diagram  around  technology  element  with  criti¬ 
cal  performance  requirements  defined.  Processor  selection  analy¬ 
sis,  Simulation/Stimulation  (Sim/Stim)  Laboratory  buildup  plan. 
Software  placed  under  configuration  management.  Commercial-of- 
the-shelf/govemment-off-the-shelf  (COTS/GOTS)  components  in 
the  system  software  architecture  are  identified. 

6 

System/subsys¬ 
tem  model  or 
prototype  dem¬ 
onstration  in  a 
relevant 
environment. 

Representative  model  or  prototype  system,  which  is  well  beyond 
that  of  TRL  5,  is  tested  in  a  relevant  environmenL  Represents  a 
major  step  up  in  a  technology's  demonstrated  readiness.  Examples 
include  testing  a  prototype  in  a  high-fidelity  laboratory  environment 
or  in  a  simulated  operational  environmenL 

Results  from  laboratory  testing  of  a  prototype  system  that  is  near 
the  desired  configuration  in  terms  of  performance,  weight,  and  vol¬ 
ume.  How  did  the  test  environment  differ  from  the  operational  envi¬ 
ronment?  Who  performed  the  tests?  How  did  the  test  compare  with 
expectations?  What  problems,  if  any,  were  encountered?  What 
are/were  the  plans,  options,  or  actions  to  resolve  problems  before 
moving  to  the  next  level? 

6 

Module  and/or 
subsystem  vali¬ 
dation  in  a 
relevant 
end-to-end 
environment. 

Level  at  which  the  engineering  feasibility  of  a  software  technology  is 
demonstrated.  This  level  extends  to  laboratory  prototype  imple¬ 
mentations  on  full-scale  realistic  problems  in  which  the  software 
technology  is  partially  integrated  with  existing  hardware/software 
systems. 

Results  from  laboratory  testing  of  a  prototype  package  that  is  near 
the  desired  configuration  in  terms  of  performance,  including  physi¬ 
cal,  logical,  data,  and  security  interfaces.  Comparisons  between 
tested  environment  and  operational  environment  analytically  under¬ 
stood.  Analysis  and  test  measurements  quantifying  contribution  to 
system-wide  requirements  such  as  throughput,  scalability,  and  reli¬ 
ability.  Analysis  of  human-computer  (user  environment)  begun. 

7 

System  proto¬ 
type  demonstra¬ 
tion  in  an 
operational 
environment. 

Prototype  near  or  at  planned  operational  system.  Represents  a 
major  step  up  from  TRL  6  by  requiring  demonstration  of  an  actual 
system  prototype  in  an  operational  environment  (e.g.,  in  an  aircraft, 
in  a  vehicle,  or  in  space). 

Results  from  testing  a  prototype  system  in  an  operational  environ¬ 
ment.  Who  performed  the  tests?  How  did  the  test  compare  with 
expectations?  What  problems,  if  any,  were  encountered?  What 
are/were  the  plans,  options,  or  actions  to  resolve  problems  before 
moving  to  the  next  level? 

7 

System  proto¬ 
type  demonstra¬ 
tion  in  an 
operational 
high-fidelity 
environment. 

Level  at  which  the  program  feasibility  of  a  software  technology  is 
demonstrated.  This  level  extends  to  operational  environment  proto¬ 
type  implementations,  where  critical  technical  risk  functionality  is 
available  for  demonstration  and  a  test  in  which  the  software  tech¬ 
nology  is  well  integrated  with  operational  hardware/software  sys¬ 
tems. 

Critical  technological  properties  are  measured  against  requirements 
in  an  operational  environmenL 

8 

Actual  system 
completed  and 
qualified  through 
test  and 
demonstration. 

Technology  has  been  proven  to  work  in  its  final  form  and  under 
expected  conditions.  In  almost  all  cases,  this  TRL  represents  the 
end  of  true  system  development.  Examples  include  developmental 
test  and  evaluation  (DT&E)  of  the  system  in  its  intended  weapon 
system  to  determine  if  it  meets  design  specifications. 

Results  of  testing  the  system  in  its  final  configuration  under  the 
expected  range  of  environmental  conditions  in  which  it  will  be 
expected  to  operate.  Assessment  of  whether  it  will  meet  its  opera¬ 
tional  requirements.  What  problems,  if  any,  were  encountered? 

What  are/were  the  plans,  options,  or  actions  to  resolve  problems 
before  finalizing  the  design? 

8 

Actual  system 
completed  and 
mission  qualified 
through  test  and 
demonstration  in 
an  operational 
environment. 

Level  at  which  a  software  technology  is  fully  integrated  with  opera¬ 
tional  hardware  and  software  systems.  Software  development 
documentation  is  complete.  All  functionality  tested  in  simulated  and 
operational  scenarios. 

Published  documentation  and  product  technology  refresh  build 
schedule.  Software  resource  reserve  measured  and  tracked. 

9 

Actual  system 
proven  through 
successful  mis¬ 
sion  operations. 

Actual  application  of  the  technology  in  its  final  form  and  under  mis¬ 
sion  conditions,  such  as  those  encountered  in  operational  test  and 
evaluation  (OT&E).  Examples  include  using  the  system  under 
operational  mission  conditions. 

OT&E  reports. 

9 

Actual  system 

proven  through 

successful 

mission-proven 

operational 

capabilities. 

Level  at  which  a  software  technology  is  readily  repeatable  and 
reusable.  The  software  based  on  the  technology  is  fully  integrated 
with  operational  hardware/software  systems.  All  software  docu¬ 
mentation  verified.  Successful  operational  experience.  Sustaining 
software  engineering  support  in  place.  Actual  system. 

Production  configuration  management  reports.  Technology  inte¬ 
grated  into  a  reuse  “wizard." 
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APPENDIX  B.  ACQUISTION  OVERVIEW  CHART 


The  Integrated  Defense  Acquisition,  Technology,  and  Logistics  Life  Cycle 
Management  System  chart  in  Figure  3  shows  complexity.  The  chart  can  be  found  on  the 
Defense  Acquisition  University’s  website  (http://www.dau.mil). 
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Figure  3. 


Integrated  Defense  Acquisition,  Technology,  and  Logistics  Life  Cycle  Management  System 


Integrated  Defense  Acquisition,  Technology,  and  Logistics  Life  Cycle  Management  System  (from  http://www.dau.mil) 
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APPENDIX  C.  OPERATIONAL  DEFICIENCY  REPORT 


The  template  below  is  a  generic  example  of  what  an  operational  deficiency  report 
could  look  like. 

From: _ 

To:  _ 

Subj :  OPERATIONAL  DEFICIENCY  REPORT  (ODR) 

1 .  Operational  Requirement.  Provide  a  brief  description  and  summary 
addressing  the  operational  requirement  (who,  what,  where,  when,  why,  how). 

a.  Capability  Required.  Describe  what  is  required  in  operational  terms. 

If  possible,  identify  the  system,  equipment,  component,  procedure, 
etc.,  that  will  provide  a  solution  to  the  operational  deficiency. 

b.  Operational  Deficiency.  Describe  the  existing  operational  deficiency 
(capability  gap).  Explain  why  existing  systems  or  procedures  fail  to 
provide  the  results  or  effects  required. 

2.  Concept  of  Operations.  Outline  the  concept  of  operations  (how  would  the 
required  kit/system/platform,  etc.)  to  be  employed  to  overcome  the 
operational  deficiency. 

3.  Additional  Supportive  Information.  Provide  additional  information,  as 
available,  that  further  clarifies/supports  the  requirement.  For  example, 

a.  Will  this  be  a  new  item,  or  will  it  replace  an  existing  item/system? 

b.  Give  the  potential  technology  or  vendor. 

c.  List  other  units/Services/organizations  that  have  a  potential  solution  or 
similar  requirement. 

4.  ODR  Sponsor  Point  of  Contact. 

5.  Signature. 
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APPENDIX  D.  ONLINE  ACQUISITION  RESOURCES 


The  following  list  describes  some  of  the  current  online  acquisition  resources  that 
should  be  consolidated  or  related  to  improve  the  Integrated  Defense  Acquisitions, 
Technology,  and  Logistics  Life  Cycle  Management  System. 

A.  DOD  TECHIPEDIA 

DoD  Techipedia  is  a  wiki  sponsored  by  the  Defense  Technical  Infonnation  Center 
(DTIC)  that  is  designed  to  increase  communication  and  collaboration  among  DoD 
scientists,  engineers,  program  managers,  and  operational  warfighters.  This  tool  enables 
DoD  personnel  to  collaborate  on  technological  solutions,  reduce  costs,  add  capability, 
and  avoid  duplication  through  a  common  wiki  (Department  of  Defense  [DoD],  n.d.c). 

The  CRC  would  gain  an  immense  knowledge  base  from  the  DTIC  because  it  is 
the  largest  central  resource  depository  for  DoD-  and  government-funded  scientific, 
technical,  engineering,  and  business  infonnation.  Specifically,  DoD  Techipedia  has 
created  relationships  between  stakeholders  (requirements  generators,  the  Federal 
Laboratory  Consortium,  acquisition  professionals,  IA,  and  interoperability  organizations) 
who  have  common  interests  within  the  DoD  in  order  to  leverage  the  collective  power  of 
the  individuals  in  the  federal  system  (DoD,  n.d.c).  This  is  one  of  the  criteria  that  the 
CRC  should  provide.  In  addition  to  the  service  provided  by  DoD  Techipedia,  the  CRC 
would  add  the  remaining  stakeholders  (private  industry  and  budget  professionals)  as 
collaborators  who  would  contribute  and  find  information  based  on  their  common 
interests. 

B.  DOD  IT  STANDARDS 

DoD  IT  Standards  was  created  by  the  Office  of  the  Secretary  of  Defense 
(Networks  &  Information  Integration)  DoD  Chief  Information  Officer,  who  is 
responsible  for  setting  policy  and  providing  oversight  of  information  processes,  systems, 
and  technologies  (http://cio-nii.defense.gov/).  DoD  IT  Standards  focuses  on  three  major 

activities:  policy  development,  program  oversight,  and  acquisition  support.  The  CRC 
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would  benefit  from  the  DoD  IT  Standards  by  pulling  standards  infonnation  from  one  up- 
to-date  source.  The  CRC  could  then  use  this  information  to  advertise  infonnation  to 
private  industry.  Furthermore,  the  CRC  could  compare  the  standards  to  standards 
advertized  by  private  industry  as  an  extra  step  of  verification  for  industry  compliance 
(Office  of  the  Secretary  of  Defense  for  Networks  &  Information  Integration,  Chief 
Information  Officer  [OSD(NII/CIO)],  n.d.). 

C.  INFORMATION  ASSURANCE  SUPPORT  ENVIRONMENT 

The  Infonnation  Assurance  Support  Environment  (IASE)  provides  a  single 
location  for  everything  related  to  IA  C&A  and  interoperability.  Similar  to  the  relationship 
between  the  CRC  and  DoD  IT  Standards,  the  IASE  would  provide  essential  IA  C&A  and 
interoperability  sources  to  the  CRC.  An  important  aspect  of  the  IASE  is  that  it  is  fed  by 
multiple  supporting  online  resources  such  as  the  NIST  Special  Publications  Computer 
Security  Division  (CSD),  which  is  responsible  for  providing  minimum  standards  and 
technology  to  protect  information  systems  against  threats.  Furthermore,  it  hosts  a 
growing  repository  of  federal  agency  security  practices,  public  and  private  security 
practices,  and  security  configuration  checklists  for  IT  products  (DoD,  n.d.b). 

D.  CONTRACTOR  PERFORMANCE  ASSESSMENT  REPORTING  SYSTEM 

A  Contractor  Perfonnance  Assessment  Reporting  System  (CPAR)  assesses  a 
contractor’s  perfonnance  and  provides  a  record,  including  both  positive  and  negative 
ratings,  on  a  given  contractor  as  dictated  by  the  FAR  (Defense  Information  Systems 
Agency  [DISA],  n.d.).  CPARS  is  a  web-enabled  application  that  collects  and  manages 
the  library  of  automated  CPARs.  Each  assessment  is  based  on  objective  facts  and  is 
supported  by  program  and  contract  management  data,  such  as  cost  perfonnance  reports, 
customer  comments,  quality  reviews,  technical  interchange  meetings,  financial  solvency 
assessments,  construction  and  production  management  reviews,  contractor  operations 
reviews,  functional  performance  evaluations,  and  earned  contract  incentives.  The  CRC 
would  pull  information  from  CPARS  and  relate  that  infonnation  to  industry  capabilities 
(past,  current,  and  future).  The  CRC  could  use  the  CPAR  data  to  provide  amplifying 
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information  to  its  query  results  for  capabilities  and  could  use  the  infonnation  to  provide 
ratings  for  products  and  contractors.  Because  the  FAR  dictates  that  past  performance 
information  (PPI)  be  collected  and  used  in  source  selection  evaluations  throughout  the 
acquisition  process,  the  CRC  would  show  the  relationships  on  a  macro  level  in  order  to 
provide  stakeholders  with  the  right  information  so  that  they  could  make  the  correct 
acquisition  decisions  (DISA,  n.d.). 

E.  GENERAL  SERVICES  ADMINISTRATION,  SOFTWARE  MANAGED 

AND  ACQUIRED  ON  THE  RIGHT  TERMS 

Software  Managed  and  Acquired  on  the  Right  Terms  (SmartBuy)  is  a  federal 
procurement  vehicle  that  provides  faster  licensed  software  and  software-related  services 
at  considerable  savings  through  established  blanket  purchase  agreements  (BP As).  The 
General  Services  Administration  (GSA)  offers  the  opportunity  to  view  and  select  from  an 
expanding  list  of  COTS  software.  The  CRC  would  pull  information  from  SmartBuy  to 
add  to  its  knowledge  base  of  products  and  their  capabilities.  As  users  or  the  system  query 
the  CRC,  the  SmartBuy  data  would  provide  an  expedited  existing  material  solution  with  a 
contracting  vehicle.  This  is  a  great  example  of  the  CRC  because  it  would  match  an 
existing  capability  with  a  current  requirement.  Furthermore,  it  would  provide  a  quick 
means  for  acquisition  because  a  contracting  vehicle  already  exists  for  the  DoD  (General 
Service  Administration  [GSA],  n.d.). 

F.  CENTRAL  CONTRACTOR  REGISTRATION 

The  Central  Contractor  Registration  (CCR)  fills  the  FAR  requirement  for 
contractors  to  register  their  companies  in  order  to  do  business  with  the  federal 
government.  It  collects,  validates,  stores,  and  disseminates  data  on  all  known  contractors 
conducting  business  with  the  DoD  (https://www.bpn.gov/ccr/default.aspx).  The  CRC 
would  pull  information  from  the  CCR  in  order  to  build  relationships  between  contractor 
names,  numbers,  and  their  products. 
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G.  CONTRACTOR  COST  AND  DATA  REPORTING 

Contractor  Cost  and  Data  Reporting  (CCDR)  is  the  authoritative  source  of 
information  associated  with  the  Cost  and  Software  Data  Reporting  (CSDR)  system. 
CSDRs  are  the  primary  means  by  which  the  DoD  collects  data  on  the  costs  that 
contractors  incur  while  working  on  DoD  programs.  CSDRs  are  the  DoD’s  only 
systematic  mechanism  for  capturing  completed  development  and  production  contract 
costs,  which  provide  more  credible  cost  estimates  for  realistic  budget  estimates  (DoD, 
n.d.a).  The  CRC  would  pull  the  CCDR  infonnation  and  relate  the  information  to 
capabilities  queried.  This  would  provide  amplifying  information  to  stakeholders  so  that 
they  could  more  accurately  make  decisions  in  acquisition  programs  and  projects. 
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